| 01:05 | <jcranmer> | where is the character encoding sniffing described? |
| 01:06 | <Philip`> | jcranmer: http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#determining-the-character-encoding ? |
| 01:07 | <jcranmer> | ども! |
| 01:07 | <Philip`> | Pardon? |
| 01:08 | <jcranmer> | thanks |
| 01:51 | <billyjackass> | wakaba: you there? |
| 05:56 | <boblet> | Phillip` are you the Phillip of http://fonts.philip.html5.org/ fame? |
| 05:58 | <boblet> | I’m interested in whether this tool can include the modifiable M+ fonts http://bit.ly/mplus as font subsetting for 350KB Japanese fonts would make them actually usable |
| 06:01 | <MikeSmith> | it's a boblet! |
| 06:01 | <MikeSmith> | boblet: こんちは |
| 06:01 | <boblet> | Hey Mike™ |
| 06:02 | <MikeSmith> | boblet, yeah, that's the same Philip` |
| 06:02 | <boblet> | ワサップ? :) |
| 06:02 | <boblet> | Found his email and sending that way just in case |
| 06:03 | <MikeSmith> | boblet: I'm enjoying the weather today |
| 06:03 | <MikeSmith> | you at home in Osaka? |
| 06:03 | <boblet> | 350KB Japanese font without subsetting plus Safari not displaying anything on load = noticeable render delay even on hikari |
| 06:03 | <MikeSmith> | Philip` is in the UK, so might not be on until 2-3 hours from now |
| 06:04 | <MikeSmith> | boblet: yeah, the Safari behavior for rendering of pages with downloadable fonts is suboptimal |
| 06:04 | <boblet> | yeah it’s fantastic down here too. I’ll be up May 15-16th for John Allsopp’s workshop tho. If you’re not busy it’d be great to catch up then |
| 06:05 | <MikeSmith> | boblet: try http://hsivonen.iki.fi/doctype |
| 06:05 | <boblet> | I plan to email the webkit list about it |
| 06:05 | <MikeSmith> | boblet: I'll be in Australia from May 8 to May 22 |
| 06:06 | <MikeSmith> | I think I'll see John there on the 13th before he comes ehre |
| 06:06 | <boblet> | aah that sucks (well, for me ;-) |
| 06:06 | <MikeSmith> | ap: me and boblet was just talking about webkit rendering of pages with downloadable fonts |
| 06:06 | <MikeSmith> | e.g., page like http://hsivonen.iki.fi/doctype |
| 06:07 | <ap> | MikeSmith: do we do it wrong? |
| 06:08 | <MikeSmith> | ap: just that you basically get no next at all while the font is downloading |
| 06:09 | <boblet> | I know the current HTML5 spec doesn’t recommend browser behavoiur atm, and laying out with local font then redrawing is kinda FOUCy for small fonts, but for double-byte (350KB+) fonts no text until download finishes looks like the page is broken |
| 06:09 | <MikeSmith> | so on hsivonen's site, which uses some relatively big fonts, there's no text content for quite a while |
| 06:10 | <ap> | MikeSmith: hmm, is http://hsivonen.iki.fi/doctype the right url? I don't see any references to downloadable fonts there |
| 06:10 | <MikeSmith> | boblet: right -- that's the problem. casual users are going to assume its's a browser bug |
| 06:10 | <boblet> | I only used @font-face for the <h1> here (dark green band) http://oli-studio.com/work/wde/200905-roadshow/ but there’s still a noticeable delay |
| 06:10 | <ap> | MikeSmith: but yeah, I saw someone complain about that - not sure if there's a bug filed |
| 06:11 | <MikeSmith> | ap: open Web Inspector on http://hsivonen.iki.fi/doctype and look at the Resources tab |
| 06:11 | <boblet> | FF 3.5 beta renders the text using a local font first then redraws. This would also be much safer if the font doesn’t finish downloading (eg server times out) |
| 06:11 | <MikeSmith> | 5MB+ of fonts there |
| 06:11 | <ap> | MikeSmith: test-quirks.php and spacer.gif |
| 06:11 | <boblet> | 5MB? I feel like small fry :D |
| 06:12 | <ap> | MikeSmith: ah, I see - I didn't notice that I got auto-completion of the url, and was looking at another page |
| 06:13 | <MikeSmith> | ap: o_0 |
| 06:13 | <MikeSmith> | boblet: ap is a webkit developer |
| 06:13 | <boblet> | MikeSmith: he’s waiting for something to display… ;-) |
| 06:13 | <ap> | MikeSmith: not one having anything to do with fonts though |
| 06:15 | <boblet> | ap: props to the Webkit team for all the fun goodies you’re giving us! and where do I go to complain about tabs not being maintained automatically between sessions? ;-) |
| 06:15 | <MikeSmith> | boblet: there's a way you can save them manually at least |
| 06:15 | <MikeSmith> | "Reopen all windows from last session" |
| 06:16 | <ap> | boblet: as MikeSmith says, it's a feature - but it's in Safari, not in WebKit, of course |
| 06:16 | <boblet> | MikeSmith: yeah I know, but I’ve had to pull previous versions of LastSession.plist out of git several times so far |
| 06:17 | <boblet> | ap: damn, foiled again! |
| 06:18 | <boblet> | ap: is Safari 4b feature complete? |
| 06:18 | <ap> | boblet: no announcements were made, as far as I know |
| 06:19 | <boblet> | ap: I guess I shouldn’t assume you have the inside track on what webkit build the Safari team will roll with huh |
| 06:23 | <olliej> | boblet: apple engineers cannot discuss anything like that :D |
| 06:25 | <olliej> | boblet: in general if apple has not announced it, we can't discuss it |
| 06:25 | <boblet> | ap: actually I came across something else a while back that I didn’t know what to make of in Webkit: Japanese text appearing to break out of it’s inline box when Hoefler Text is assigned: http://oli-studio.com/code/font-set-inline-box.html |
| 06:25 | <olliej> | boblet: filing a bug at bugs.webkit.org would be great :D |
| 06:25 | <boblet> | olliej: heh, indeed. It’s part of Apple’s charm |
| 06:26 | <olliej> | boblet: hey, at least we do our development publically |
| 06:26 | <olliej> | boblet: for the purposes of engine development the "webkit team" == Apple :D |
| 06:26 | <boblet> | olliej: yeah I think that was next on the list of things to do, right before Christmas attacked |
| 06:29 | <olliej> | boblet: ah, you're talking about the top overflow? |
| 06:30 | <boblet> | olliej: I may well be.…? |
| 06:30 | <ap> | boblet: try Apple Chancery - I think it may break out even more. likely a known issue, but filing a bug is the best way to reach people who work on text rendering |
| 06:31 | <boblet> | ap: ok. I’ll do that for both issues |
| 06:31 | <olliej> | boblet: and link in your testcase -- we love testcases |
| 06:31 | <boblet> | I kinda went overboard on that one huh |
| 06:31 | <olliej> | boblet: bugs are vastly more likely to be fixed with a reduced testcase |
| 06:32 | <olliej> | boblet: vs. entire bug content being "japanese text overflows with the Hoefler Text font" |
| 06:32 | <olliej> | boblet: i'm guessing the font is giving "interesting" metrics to us |
| 06:32 | <boblet> | olliej: ok. I’ll make a reduced version and link it from the fat version |
| 06:33 | <olliej> | boblet: even your current version is vastly better than what we normally get |
| 06:33 | <olliej> | so i'd initially file a bug that links to that url |
| 06:47 | <hsivonen> | ap: already filed https://bugs.webkit.org/show_bug.cgi?id=25207 |
| 06:48 | <ap> | hsivonen: thanks |
| 07:08 | <zcorpan_> | Hixie: "if the user agent has not fired a timeupdate event at the element in the past 15 to 250ms" -- s/15 to // ? |
| 07:09 | <Hixie> | zcorpan_: UAs are allowed to do it every 15ms |
| 07:09 | <zcorpan_> | Hixie: yes, but if it hasn't fired it in hte past 250ms, then it won't have fired it in the past 15ms either |
| 07:10 | <zcorpan_> | oh wait |
| 07:10 | <zcorpan_> | nm |
| 07:11 | <Hixie> | zcorpan_: :-) |
| 07:21 | <weinig> | hi olliej |
| 08:01 | <jgraham> | boblet: Note that afaict Philip`'s natural biological rhythms seem to place him somewhere in the mid atlantic timezone wise so it may yet be a while before he is around |
| 08:02 | <boblet> | jgraham hehe, thanks. I’m gonna email him just in case |
| 08:03 | <MikeSmith> | jgraham: you up early. 8am now? |
| 08:04 | <jgraham> | MikeSmith: 9am here |
| 08:04 | jgraham | wonders what kind of weird algorithm Apple are using where 0% battery life = 15 minutes of reamining time |
| 08:05 | <jgraham> | (and it really was 0% because the power suddenly died) |
| 08:06 | <Hixie> | jgraham: i have the opposite experience |
| 09:03 | <Philip`> | boblet: That's me :-) |
| 09:03 | <Philip`> | Oh, you're not here |
| 09:23 | <a-ja> | !seen hsivonen |
| 09:25 | <MikeSmith> | a-ja: no bots here, only peoples |
| 09:25 | <MikeSmith> | I think hsivonen is awake but busy |
| 09:25 | <a-ja> | tks Mike |
| 10:27 | <MikeSmith> | hendry : I've put together part of a HTML document splitter in XSLT |
| 10:28 | <MikeSmith> | mostly just by borrowing stuff from that Docbook XSL stylesheets distro |
| 10:28 | <MikeSmith> | I still need to get the in page next/prev/up/down navigation stuff working |
| 10:30 | <Philip`> | You get bonus points for including the relevant TOC extract at the top of each page |
| 10:30 | <MikeSmith> | Docbook stylesheets have a way to do that, but I'm not using it |
| 10:31 | <MikeSmith> | default output from DocBook stylesheets looks like this: |
| 10:32 | <MikeSmith> | http://docbook.sourceforge.net/release/xsl/current/doc/html/chunker.output.cdata-section-elements.html |
| 10:32 | <MikeSmith> | includes the major section name in the page header |
| 10:32 | <MikeSmith> | title |
| 10:32 | <MikeSmith> | and the titles of the next page and previous page in teh footer |
| 11:37 | <Philip`> | http://www.tbray.org/ongoing/When/200x/2009/04/29/Model-and-Syntax - "I have long believed and repeatedly written that bits on the wire are the only serious reliable basis for interoperability, and worried in public about the feasibility of shared models" |
| 11:38 | <Philip`> | That seems kind of completely opposite to the HTML 5 philosophy, which is that the document model is the important thing, and the bits on the wire are just one of many ways of serialising the model |
| 11:39 | <MikeSmith> | Philip`: interesting |
| 11:40 | Philip` | wonders how the connect the different viewpoints |
| 11:40 | <MikeSmith> | I wonder if that's a key difference between some of the people who come from same background and Tim, and, say, browser implementors or client-side web-apps developers |
| 11:41 | <jgraham> | Philip`: Since HTML5 defines exactly how you get from bits on the wire to the internal model and back again, I'm not so sure that's true |
| 11:41 | <MikeSmith> | hmm, "I believe the existence and success of the Internet and the Web are strong evidence in my favor. They have no object models or APIs; nor could they: they are just a collection of agreements what bits we send each other, with accompanying narrative about what those bits are supposed to mean." |
| 11:42 | <MikeSmith> | is that statement accurate? |
| 11:43 | <Philip`> | jgraham: But the main basis for interoperability is the rules for how UAs process the document model, and isn't just about the syntax |
| 11:43 | <Philip`> | unlike XML, which is defined as purely syntax |
| 11:44 | <MikeSmith> | Philip`: yeah, that seems to me too like an accurate way to describe it |
| 11:44 | <zcorpan> | MikeSmith: the Web uses script, and the scripts assume the DOM as the model |
| 11:44 | <jgraham> | What zcorpan said |
| 11:44 | <Philip`> | (and that purely syntactic definition causes problems with e.g. when do you execute <script>s while parsing XHTML, so the model is valuable too) |
| 11:45 | <jgraham> | I don't see how the idea of client side scripting fits with the "it's all just bits" viewpoint |
| 11:45 | <jgraham> | (that applies to XML too of course) |
| 11:47 | <jgraham> | """I’ll tell you this: As a TDD disciple, if I read the initial spec language, I’d have cooked up a bunch of test cases that would have explored the value space pretty thoroughly before I shipped any code. Tighten the spec and I might have gotten lazy.""" |
| 11:47 | <jgraham> | That is the single worst defence of bad specs I have ever read |
| 11:48 | <MikeSmith> | this makes me think of the discussion about the whether it's a mistake to attempt to separately spec a particular language without in the same document also specifying how it is meant to be processed |
| 11:49 | <MikeSmith> | jgraham: yeah, on the face of it, that seems not particularly compelling argument |
| 11:49 | <Philip`> | It still seems true that bits-on-the-wire are important by themselves - people think of HTML and XML as character strings, and that's a useful and successful view, and we'd lose that if we just had the DOM API and some unreadable custom binary protocol for transferring DOMs |
| 11:49 | <MikeSmith> | btw, what's TDD? |
| 11:49 | <Philip`> | Test-driven development |
| 11:49 | <MikeSmith> | ah |
| 11:51 | <Philip`> | I suppose the focus on bits-on-the-wire vs document models could also be blamed for e.g. RSS readers that just use regexps to interpret those bits |
| 11:53 | <MikeSmith> | Philip`: yeah, good example i guess |
| 11:53 | <MikeSmith> | that's a genuine problem |
| 11:54 | <Philip`> | Maybe the bits-on-the-wire view is more useful during the early stages of a protocol, when we want to encourage competition between widely varying ways of implementing and using the protocol; but as the technology matures, the dominant document model should be specified and standardised, to improve interoperability |
| 11:54 | <MikeSmith> | mooncalves writing parsers in regex |
| 11:54 | <MikeSmith> | Philip`: seems like that's the way it evolved with HTML anyway |
| 11:55 | <Philip`> | Maybe RSS->Atom could be seen the same way? |
| 11:55 | <MikeSmith> | yeah |
| 11:56 | Philip` | can't think of any other examples... |
| 11:56 | <MikeSmith> | well, maybe XML processing in general could not evolve that way because of you-know-what |
| 11:57 | <MikeSmith> | spec'ing catch-fire-and-fail error handling seems like a pretty good way to stop natural evolution |
| 11:57 | <Philip`> | I don't quite see why that's relevant |
| 11:58 | <Philip`> | Someone could define a processing model for XML that turns a stream of bytes into a DOM or Infoset or SAX stream or whatever, and that'd solve the questions about when scripts execute and how document.write could be fitted in etc, but they don't seem to have done that yet |
| 11:58 | <Philip`> | (and draconity doesn't have anything to do with that, as far as I can tell) |
| 11:58 | <MikeSmith> | Philip`: if you want processing applications to be able do deal with content that people actually produce, rather than the content you assume ahead of time they will produce |
| 11:59 | <Philip`> | (There's also things like Jabber which rely somewhat on the processing model of XML parsers, e.g. elements should be reported as soon as their close tag's '>' is seen) |
| 12:01 | <MikeSmith> | as far as the mention that Tim makes of agreements: the agreements in the case of browsers have been a moving target |
| 12:02 | <MikeSmith> | "unstable equilibrium" I think is how hsivonen or someone referred to i |
| 12:02 | <MikeSmith> | it |
| 12:03 | Philip` | goes away for a bit |
| 13:38 | <Philip`> | http://img.thedailywtf.com/images/200904/mandelbrot.xml - ouch |
| 13:46 | <annevk42> | respect |
| 13:51 | <heycam> | very nice! |
| 13:54 | <heycam> | zot:~ $ lynx -dump -nolist http://www.w3.org/TR/SVG/refs.html | grep -B1 -A3 fixme # whoops... |
| 13:54 | <heycam> | [XHTMLplusMathMLplusSVG] |
| 13:54 | <heycam> | @@fixme "An XHTML + MathML + SVG Profile", M. Ishikawa editor, 9 |
| 13:54 | <heycam> | August 2002. |
| 13:54 | <heycam> | Available at: |
| 13:54 | <heycam> | http://www.w3.org/TR/2002/WD-XHTMLplusMathMLplusSVG-20020809/ |
| 13:54 | <heycam> | actually i wonder what the fixme is for |
| 13:55 | <heycam> | doesn't look like that document got past WD anyway |
| 13:57 | <annevk42> | hey heycam |
| 13:57 | <heycam> | hey annevk42 |
| 13:57 | <annevk42> | heycam, do you know when you're going to edit webidl again? |
| 13:58 | <annevk42> | I was wondering if it could provide some hook for when an interface object is accessed |
| 13:58 | <heycam> | ar, when i get some time. i can certainly add some notes for features, with particular syntax, so you can start using it.. |
| 13:58 | <annevk42> | e.g. if a script does var something = somewindow.XMLHttpRequest or var x = new XMLHttpRequest() I need an implementation to set some internal variables on the interface object (later copied to the constructed object) |
| 13:59 | <heycam> | sounds weird :) |
| 13:59 | <heycam> | what needs it? |
| 14:00 | <heycam> | (the latter you could just define things to happen in the constructor) |
| 14:00 | <annevk42> | xhr needs some kind of pointer to the Document object |
| 14:01 | <heycam> | and it needs to grab it at exactly the time somewindow.[[Get]]("XMLHttpRequest") is done? |
| 14:01 | <annevk42> | if it grabs it later the current document could be away |
| 14:02 | <Philip`> | What if somewindow does "window.foo = window.XMLHttpRequest" and then someone else does somewindow.[[Get]]("foo")? |
| 14:03 | <annevk42> | Philip`, it should be bound to the initial window |
| 14:03 | <annevk42> | I wonder how localStorage/sessionStorage solves this |
| 14:04 | <heycam> | i think i'm not understanding excatly what needs to happen |
| 14:04 | <heycam> | ...and i'm being called to go to bed. can you mail public-webapps annevk42? |
| 14:04 | <annevk42> | k |
| 14:04 | <heycam> | thanks |
| 14:26 | <annevk42> | Philip`, afaict it is bound the initial time it is accessed |
| 14:34 | <MikeSmith> | "If you were to use The Daily WTF as a guide, your impression of XSL Transformations (XSLT) would probably be fairly low. I mean, seeing article after article after article might have given the impression that XSLT is often not the right tool for the job... or, perhaps, maybe not even a right tool. Period." |
| 14:35 | <MikeSmith> | http://thedailywtf.com/Articles/Where-the-Wild-Web-Things-Are.aspx is nice too |
| 14:35 | <MikeSmith> | (great find by Hallvord R. M. Steen) |
| 14:37 | <Philip`> | I wish free fonts were more discoverable |
| 14:37 | Philip` | found some GFDL ones for the Khmer language, wrapped inside an .exe installer on a Yellow Pages site |
| 14:38 | <Philip`> | (The comments inside the font point at a Geocities site which shows the default placeholder page) |
| 14:38 | <Philip`> | s/GFDL/LGPL/ |
| 14:52 | <wakaba> | MikeSmith: ? |
| 14:53 | <MikeSmith> | wakaba: was going to ask you off-topic question |
| 14:54 | <MikeSmith> | which is, I see you're using a e-mobile modem |
| 14:54 | <wakaba> | yeah |
| 14:54 | <MikeSmith> | and was wondering if there's a way to get around the arbitrary time limit |
| 14:55 | <MikeSmith> | or maybe if they have changed the time-limit thing |
| 14:55 | <MikeSmith> | specifically, the driver I have on my Mac OSX machine drops that connection after 6 hours or use |
| 14:56 | <wakaba> | my connection seems also time limited |
| 14:56 | <wakaba> | i don't know how to avoid it... |
| 14:59 | <wakaba> | i was offline today because and redial feature did not work for some reason... |
| 15:00 | <MikeSmith> | wakaba: I see |
| 15:01 | <MikeSmith> | I seem to rembember somebody telling me that there is a newer driver that doesn't have the time limit, but maybe I imagined that |
| 15:03 | annevk42 | hopes his email is clear enough for heycam |
| 16:42 | <gsnedders> | Why do I think having a sprained ankle the day before the ball is not a good idea? |
| 16:42 | <Philip`> | It provides you with a good excuse to not dance |
| 16:43 | <Philip`> | On the other hand, it will be harder for you to run away from any nearby bombs or aliens |
| 17:29 | <mpilgrim> | grr http://lists.w3.org/Archives/Public/public-html/2009Apr/0260.html |
| 17:31 | <mpilgrim> | "W3C HTML5 spec" |
| 17:31 | <mpilgrim> | i can't decide if this is intentionally divisive or just stupid |
| 17:32 | <mpilgrim> | if it had come from sam, i would guess "intentionally divisive," but here i'm gonna go with "stupid" |
| 17:35 | <Philip`> | Sounds quite reasonable to me, as a way of referring to the document that's published by the W3C and is called "HTML5" |
| 17:35 | <Philip`> | ...and is a spec |
| 17:58 | <Hixie> | http://www.w3.org/mid/FAA1D89C5BAF1142A74AF116630A9F2C0A26ED872D⊙Ooac - money first, principles after |
| 18:02 | Hixie | wonders what to do about <header> |
| 18:04 | <Philip`> | Rename it to <hgroup> |
| 18:04 | <Philip`> | and then create a new element called <header> |
| 18:04 | <Philip`> | which is basically equivalent to <div class=header>, because people want semantic elements |
| 18:05 | <Philip`> | Easy :-) |
| 18:05 | <Hixie> | yeah that was basically what i was thinking of doing |
| 18:05 | <Hixie> | if i do that i'll change <hgroup>'s content model to just be <hx>+, i think |
| 18:05 | <Hixie> | and make <header> not participate in any special stuff like sectioning |
| 18:06 | <Hixie> | does that make sense? |
| 18:07 | <Philip`> | I think it makes sense to me, but I don't think there's much correlation between that and whether it's actually a good idea or not |
| 18:08 | <Philip`> | But if you do those changes, then you could drop <hgroup> from HTML5, and add it back into HTML6 if it turns out that people actually use the outlining algorithm and want to avoid the minor unsightliness of empty sections |
| 18:09 | <Hixie> | given that every w3c spec does the h1-h2 thing at the start, i think it's clear that either the outlining algorithm is wrong without hgroup, or we need hgroup |
| 18:22 | <a-ja> | hmmm...when did header element morph into hgroup ? |
| 18:22 | <Hixie> | about 5 minutes ago |
| 18:22 | <Hixie> | i'm about to check in the change and then introduce a new element to do more of a site-wide heading thing |
| 18:23 | <Hixie> | why, is it a bad idea? :-) |
| 18:23 | <a-ja> | don't forget the examples :) |
| 18:26 | <Hixie> | a-ja: i think i got them all |
| 18:26 | <a-ja> | not a bad idea as far as i'm concerned. i'll just need to update soame pages/templates/stylesheets |
| 18:28 | <Philip`> | Because you're currently using <header> on those pages? |
| 18:28 | <a-ja> | yep |
| 18:28 | <Philip`> | What purpose are you using it for? |
| 18:28 | <Philip`> | (like, is it actually to group multiple <hX> elements?) |
| 18:29 | <krijnh> | Wasn't <header><hx>..</hx><p>Tagline</p></header> correct usage as well? |
| 18:30 | <a-ja> | was using it per spec....h1's & h2's, sometimes with a p in it too |
| 18:30 | <Philip`> | krijnh: It used to be, but now you can't do that with <hgroup> |
| 18:30 | <a-ja> | what krijnh said :) |
| 18:30 | <krijnh> | With <hgroup> that's a bit weird indeed |
| 18:30 | <krijnh> | <heading> would be better, I think |
| 18:30 | <Philip`> | Why do you want to group the <p> with the <hx>? |
| 18:30 | <a-ja> | no more flow content? |
| 18:31 | <krijnh> | <header> sounds too much like it replaces <div id="header"> |
| 18:32 | <Hixie> | i plan to introduce a new element called <header> that can act as a more generic container for header-like content |
| 18:32 | <a-ja> | Philip`: tagline/slogan sorta thing, as opposed to a subtitle |
| 18:32 | <Hixie> | including <nav> |
| 18:32 | <Hixie> | more on par with "article" than what <header> used to be |
| 18:32 | <Hixie> | and <hgroup> now only accepts h1-h6 |
| 18:32 | a-ja | like addition of nav |
| 18:33 | <krijnh> | Hixie: a document-wide header thingy? |
| 18:33 | <a-ja> | search form, too? |
| 18:34 | <Hixie> | i could go either way, document-wide or something else |
| 18:34 | <Hixie> | what do people want? |
| 18:34 | <Hixie> | i could make it that it can't be in a section other than <body> |
| 18:34 | <krijnh> | I use <div id="header"> a lot |
| 18:34 | <krijnh> | With navigation, search, logo, that stuff |
| 18:34 | <Philip`> | It's quite common to have >1 <div class=header> on a page |
| 18:35 | <Hixie> | probably just make it equivalent to a <div> then, except with slightly more semantic juice |
| 18:35 | <Philip`> | Uh, I think I mean <* class=header> |
| 18:36 | <krijnh> | Hixie: is that enough for a new element then? |
| 18:36 | <Philip`> | http://lists.w3.org/Archives/Public/public-html/2009Mar/0679.html - oh, good, someone already counted it |
| 18:36 | <a-ja> | implicit role=banner |
| 18:36 | <a-ja> | w/o override ? |
| 18:36 | <krijnh> | Philip`: also have data for id="header" ? |
| 18:37 | <Philip`> | krijnh: I doubt many people have >1 id="header" on a page :-p |
| 18:37 | <krijnh> | That's not what I mean :) |
| 18:38 | <Philip`> | What do you mean, then? :-) |
| 18:39 | <krijnh> | How many pages uses id="header" as a page-wide thingy |
| 18:39 | <krijnh> | Also, the class="header" numbers also include <hx> and <p>, I guess? |
| 18:40 | <Philip`> | Out of ~130K, I see 11754 pages with one id=header |
| 18:40 | <Philip`> | and 71 with 2 |
| 18:40 | <Philip`> | and 8 with 3 |
| 18:40 | <Philip`> | and 15 with 4 |
| 18:40 | <Philip`> | and 2 with 5, and 2 with 6 |
| 18:40 | <Philip`> | and 1 with 8, and 1 with 17 |
| 18:40 | <Philip`> | Someone should tell them that id is meant to be unique :-/ |
| 18:41 | <krijnh> | Heh :) |
| 18:41 | <Philip`> | The class=header numbers include all elements, I believe |
| 18:41 | <krijnh> | So more id="header" usage than class="header" |
| 18:41 | <Philip`> | Yes, by approximately a factor of 4 |
| 18:41 | <krijnh> | Yeh |
| 18:42 | <krijnh> | And now the cases where class is used only on <div> and <td>? :) |
| 18:42 | <krijnh> | That's probably what something like <hgroup> represents |
| 18:42 | <Hixie> | when i did some studies on id="" i found some pages with thousands of duplicate IDs |
| 18:43 | <krijnh> | Glad I'm not a browser developer |
| 18:45 | <Philip`> | I see 896 id="menu_categories" on one page |
| 18:56 | <Hixie> | ok new text is in |
| 18:56 | <Hixie> | what do people think |
| 18:57 | <krijnh> | Hixie: to mark up a page's title? |
| 18:58 | <Hixie> | i mean, what do you think of the next text :-) |
| 18:58 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#the-hgroup-element http://www.whatwg.org/specs/web-apps/current-work/#the-header-element |
| 19:00 | gsnedders | dislikes the change, as it means his implementation of the outlining algorithm has to change |
| 19:00 | <gsnedders> | (And that requires effort) |
| 19:00 | <a-ja> | heh |
| 19:00 | <a-ja> | henriwill curse you, too |
| 19:01 | <gsnedders> | I will strike a curse in the name of the Lord, and two she-bears will appear from the woods and maul the annoying youths to death! |
| 19:01 | <krijnh> | Hixie: yeah, isn't it to mark up a section's title with its subtitle or tagline? |
| 19:01 | <Hixie> | gsnedders: s/header/hgroup/ is the only change you have to make i think |
| 19:01 | <gsnedders> | Hixie: So do I. |
| 19:01 | <gsnedders> | Hixie: Then hg commit; hg push, and then manually update the copy of the outliner on my server |
| 19:01 | <Hixie> | krijnh: i don't understand your question |
| 19:02 | <krijnh> | I don't understand the line 'The hgroup element represents the header of a section. The element is used to group a set of h1�h6 elements to mark up a page's title with its subtitle or tagline.' |
| 19:02 | <Hixie> | ohhhh |
| 19:02 | <Hixie> | hm |
| 19:02 | <krijnh> | :) |
| 19:02 | <Hixie> | that was the text that was there before |
| 19:02 | <Hixie> | let's see |
| 19:02 | <Hixie> | i'm sure it can be improved |
| 19:02 | Hixie | pokes |
| 19:02 | <gsnedders> | http://www.biblegateway.com/passage/?search=2%20Kings%202:23-25;&version=31; is what I was referencing above |
| 19:03 | <gsnedders> | Hixie: Also see the bug in bugzilla about header |
| 19:03 | <gsnedders> | (and sectioning roots) |
| 19:03 | <gsnedders> | Or have you looked at that? |
| 19:03 | gsnedders | RTFS |
| 19:04 | <Hixie> | which one? |
| 19:04 | <gsnedders> | The one I was meaning.\ |
| 19:05 | <Hixie> | -_- |
| 19:05 | gsnedders | looks |
| 19:05 | <Hixie> | krijnh: look in about 90 seconds and tell me if the new text is clearer |
| 19:05 | <krijnh> | Oki |
| 19:06 | <gsnedders> | Hixie: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6750 |
| 19:06 | <gsnedders> | "The hgroup element represents the header of a section." v. "The header element represents a header for the section it applies to." |
| 19:06 | <gsnedders> | Um, yeah. |
| 19:07 | <krijnh> | Yeah, I don't really get it either :) |
| 19:07 | <gsnedders> | Hixie: Write a better pec. |
| 19:07 | <gsnedders> | *spec |
| 19:08 | <Hixie> | hmm |
| 19:08 | <Hixie> | wonder how to distinguish these |
| 19:08 | <Hixie> | h1-h6 also "define headers for their sections" |
| 19:08 | <krijnh> | Why do we need hgroup again? |
| 19:09 | <Hixie> | subheadings |
| 19:09 | <Hixie> | as in every w3c spec for instance |
| 19:09 | <Hixie> | and taglines, as seen on most blogs |
| 19:09 | <krijnh> | Yeah, why not just use <header><hx>..</hx><p>Subheading</p></header> ? |
| 19:09 | <Hixie> | doesn't seem as right to me :-) |
| 19:10 | <krijnh> | And say that a p element in a header should be seen as a subheading :) |
| 19:10 | <Hixie> | i mean, what's the difference between that <p> and a <p>Last Modified: ...</p> or <p>Site links: ...</p> ? |
| 19:10 | <krijnh> | Why should there be a difference? |
| 19:11 | <krijnh> | For outliners? |
| 19:12 | <Hixie> | krijnh: amongst other things, yeah |
| 19:17 | <krijnh> | It's better now, and I like the new <header> |
| 19:17 | <a-ja> | fwiw, only reason i'd been using p instead of h2 for tagline was cuz it played better with CITA's toolbar |
| 19:19 | <krijnh> | Hixie: does a <header> require a <hx> ? |
| 19:21 | <Hixie> | krijnh: no |
| 19:22 | <Hixie> | a-ja: hopefully when they support <hgroup> that will no longer be n issue |
| 19:22 | <a-ja> | gives em something to do next semester:) |
| 19:23 | <tantek> | Hixie, what is <hgroup> ? |
| 19:24 | <Hixie> | groups <h1>-<h6> elements so you can have subheadings without implying a subsection |
| 19:24 | <Hixie> | the way, e.g., most w3c specs do |
| 19:24 | <krijnh> | Formerly known as <header> |
| 19:27 | <tantek> | so <hgroup> is a renaming of <header> ? if so, curious about the reasons for the renaming. |
| 19:27 | <Hixie> | we wanted to introduce a new element that was more of a generic header element |
| 19:28 | <Hixie> | since that's what people used the old <header> for |
| 19:29 | <Hixie> | oh hey while you're here tantek it would be good to have your feedback on the use cases listed in this e-mail: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019374.html |
| 19:29 | <krijnh> | The <header> example now contains text which should be in the <footer> :) |
| 19:29 | <krijnh> | Isn't <header> / <footer> really a presentational issue now? |
| 19:29 | <Hixie> | tantek: in particular, which requirements or use cases you think we shouldn't address, and which you think are already addressed |
| 19:30 | <Hixie> | tantek: and if you have any ideas on addressing the ones that aren't yet addressed |
| 19:30 | <krijnh> | "A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like." |
| 19:30 | <Hixie> | krijnh: it's not really presentational, but it's certainly easy to see how an Architect might consider them the same thing and merge them into one element |
| 19:31 | <tantek> | Hixie, general comment, the scenarios seem fairly reasonable overall, and yet the requirements appear to be fairly arbitrary, in many cases unnecessary, and disconnected from the scenarios. |
| 19:31 | <Hixie> | krijnh: updated the intro paragraphs for <hgroup> and <header>, let me know if they're more understandable now |
| 19:31 | <tantek> | In my experience, whenever requirements are disconnected from scenarios, the requirements have been artificially written to pre-suppose a specific solution. |
| 19:32 | <Hixie> | yeah that was my general impression too |
| 19:32 | <tantek> | In otherwords, the requirements should be derived from the scenarios |
| 19:32 | <tantek> | and scenarios really should be derived from real world web publishing examples (with URLs provided) |
| 19:33 | <tantek> | any requirements that are not derived from a scenario should be labeled hypothetical/a-priori and dropped |
| 19:33 | <Hixie> | okie dokie. sounsd basically like what i figured. if you have any specific comments on any of the issues, drop me a mail, i'm planning on looking at these in more detail relatively soon. |
| 19:34 | <krijnh> | Hixie: s/(An/(an/ but other than that I think it's better |
| 19:34 | <tantek> | any scenarios which do not withstand the test/request for basis in real world web publishing examples (with URL) should be considered "second class" / optional in comparison to scenarios bounded in real world web publishing examples. |
| 19:35 | <tantek> | in otherwords, I am not against "new"/theoretical scenarios, because that's often how new problems are solved. however, solutions should solve existing real world problems first, and new/theoretical problems second IMHO. |
| 19:35 | <tantek> | it's a matter of prioritization |
| 19:39 | <tantek> | one exception to the requirements feedback - it's reasonable to consider requirements that are based on well known/practiced/tested principles of data format design. this of course depends on agreeing/disagreeing on principles. |
| 19:39 | <tantek> | for example this requirement: |
| 19:39 | <tantek> | "Machine-readable event data shouldn't be on a separate page than |
| 19:39 | <tantek> | human-readable dates." |
| 19:40 | <tantek> | could be expressed as a specific instance of the DRY (don't repeat yourself) principle. |
| 19:41 | <tantek> | and perhaps even a specific subrequirement of "Should be unlikely to get out of sync with prose on the page." |
| 19:42 | <tantek> | Just to point out one egregious requirement (which I think is quite questionable). |
| 19:42 | <tantek> | This one sounds highly theoretical until/unless sufficient real world examples (with URLs) are provided that demonstrate the need: "Should be possible for different parts of an event to be given in |
| 19:42 | <tantek> | different parts of the page. For example, a page with contact details |
| 19:42 | <tantek> | for people in columns (with each row giving the name, telephone |
| 19:42 | <tantek> | number, etc) should still have unambiguous grouped contact details |
| 19:42 | <tantek> | parseable from it." |
| 19:43 | <Hixie> | tantek: that particular one has been demonstrated to me several times, though i don't have URIs handy right now |
| 19:43 | <tantek> | (note the typo "an event" in that requirement, as it was obviously copy-pasted from the previous version which has the same theoreticalness flaw |
| 19:43 | <tantek> | "Should be possible for different parts of an event to be given in |
| 19:43 | <tantek> | different parts of the page. For example, a page with calendar events |
| 19:43 | <tantek> | in columns (with each row giving the time, date, place, etc) should |
| 19:43 | <tantek> | still have unambiguous calendar events parseable from it." |
| 19:44 | <Hixie> | but basically there are people who want to add events, contacts, etc, to pages that aren't conforming, and won't be conforming |
| 19:44 | <Hixie> | and they're willing to use rdfa rather than microformats because of this requirement (!) |
| 19:45 | <Hixie> | myspace was the main example of this, but i've been shown others |
| 19:45 | <tantek> | without the URIs to specific examples, arguments about what solution to use are then based in theory/religious reasoning rather than actual practicality |
| 19:45 | <tantek> | which is ironic for an requirement based on "pages that aren't conforming, and won't be conforming" - which is obviously an appeal to practicality |
| 19:46 | <Hixie> | one example would google's internal contacts app |
| 19:46 | <Hixie> | which has the information about the main person intermixed with manager information and reportees information |
| 19:47 | <tantek> | it seems to be against reason to suggest a set of complex solutions/changes (rdfa) to a page that won't accept simple solutions/changes (conformance) |
| 19:48 | <Hixie> | yeah i don't understand why they don't just hack hcard to support what they want in the myspace case |
| 19:48 | <tantek> | also, regarding microformats for relating pieces of data across a document, this has been solved for quite some time with the "include-pattern". http://microformats.org/wiki/include-pattern |
| 19:48 | <tantek> | hResume uses it for example, to avoid duplicating a person's name in every job experience entry |
| 19:49 | <tantek> | Hixie, what often happens in many more complex markup cases, is the authors of those complex markup cases *assume* they can't use a simple solution, and immediately leap to a more complex solution because they think they are sufficiently knowledgeable about simple solutions to come to that conclusion. |
| 19:49 | <tantek> | They're almost always wrong. |
| 19:50 | <Hixie> | frankly microformats' lack of a clear parsing specs nor any apparent movement towards creating any has hurt its credibility significantly amongst a lot of the people who contributed feedback here |
| 19:50 | <tantek> | What such authors should do is first ask: "how do I markup example XYZ with microformats" |
| 19:50 | <tantek> | rather than assuming it's not possible |
| 19:50 | <a-ja> | they working on fixing date/time abbr-abuse? |
| 19:51 | <Hixie> | tantek: no argument from me there |
| 19:51 | <Hixie> | tantek: but for some reason, they are making that leap anyway |
| 19:51 | <tantek> | a-ja - "abuse" is not really a proper characterization of the problem. in particular, the real problems have been with accessibility and localization, and yes, working on that problem is what Ben Ward and I have been focusing on for perhaps the past 6-9 months |
| 19:52 | <tantek> | we have an alpha draft (feature complete) of a solution and are tweaking it: http://microformats.org/wiki/value-excerption-pattern |
| 19:52 | <tantek> | Hixie, such leaps typically indicate some degree of arrogance |
| 19:52 | <tantek> | a-ja - sorry this is the proper URL: http://microformats.org/wiki/value-class-pattern |
| 19:52 | <Hixie> | tantek: clearly, but what do we do about it? |
| 19:53 | <tantek> | a-ja, if you want to explore / discuss the value-class-pattern further, feel free to bring it up in #microformats |
| 19:53 | <a-ja> | will do.....reading |
| 19:54 | <tantek> | Hixie, I typically do http://microformats.org/wiki/mailing-lists#Point_out_logical_flaws |
| 19:54 | <krijnh> | Isn't #microformats busy enough already? ;) |
| 19:55 | <Hixie> | tantek: that doesn't scale; people are making this mistake without us knowing about it. |
| 19:55 | <tantek> | Hixie, there are two cases |
| 19:56 | <tantek> | either they bring the examples to your attention (as you have stated), at which point, you point out the logical flaw(s) in their reasoning/assumptions, preferably with URLs to the logical flaws explaining them further |
| 19:57 | <tantek> | OR they don't bring the examples to you, and you don't know about, and they go off and invent their own random XML/RDF/JSON/tab-delimited/comma-separated format. in which case, let them perform such a science experiment, from which everyone can learn. |
| 19:57 | <Hixie> | tantek: it stops being a science experiment when companies like Yahoo! actively evangelise the use of RDFa in text/html to solve actual problems they perceive authors want solving |
| 19:58 | <tantek> | a-ja, thanks and appreciated. Ben and I are iterating rapidly on that document and so now is a very good time for feedback and improvements. |
| 19:59 | <tantek> | Hixie, most authors glaze over at the very first mention of namespaces and the complexities that brings with it. Nevermind the historically bad (more than deserved) marketing that RDF has gotten. So this is not really a problem. Big companies evangelize all sorts of science experiments that go nowhere. I can't count the number of XML formats Microsoft has evangelized that have been abandoned. And for Yahoo - how well is MediaRSS |
| 20:00 | <Hixie> | there's plenty of random ccREL crap on the web now |
| 20:00 | <tantek> | and plus, as soon as a big company evanglizes something, then it brings it back to the first case, you know about it, can ask for real world examples, and can point out the logical flaw(s) in their reasoning/assumptions |
| 20:01 | <a-ja> | tantek: maybe date/time examples using html5 time element? |
| 20:01 | <tantek> | Hixie, before ccREL, there was the creative commons RDF vocabulary that they embedded in HTML comments - that failed as well. |
| 20:01 | <Hixie> | when i did that with the yahoo! case, they said their customers (including e.g. myspace) found microformats didn't solve their problems and that's why they supported rdfa as well. |
| 20:02 | <Hixie> | tantek: depends how you define "failed" |
| 20:02 | <Hixie> | tantek: it's all over the web |
| 20:02 | <Hixie> | tantek: it's wasted countless man hours |
| 20:02 | <tantek> | Hixie, authors are no longer actively publishing it, and no one is building tools to depend on it. |
| 20:02 | <Hixie> | no, they're publishing the new ccREL crazyness instead |
| 20:03 | <tantek> | Hixie, it's not really wasted, in the same way as testing flawed scientific theories is not wasted. Either way science makes progress, by documenting what doesn't work as well as what does. |
| 20:03 | <Philip`> | rel="license" is the 39th most common rel value, in some set of data |
| 20:03 | <Philip`> | on about 0.4% of pages |
| 20:04 | <Philip`> | rel="cc:attributionURL" is 184th, on about 0.02% |
| 20:04 | <tantek> | Philip`, right. rel="license" was introduced as a microformat back in 2004, and took off rapidly, in comparison to the "official" solution of creative commons RDF in HTML comments. |
| 20:04 | <tantek> | the simpler unofficial solution far outdid the complex official solution |
| 20:04 | <tantek> | this is not the first time this has happened, and won't be the last |
| 20:05 | <Philip`> | (xmlns:cc is on about 0.03% of the pages) |
| 20:05 | <tantek> | a-ja, current microformats documentation of HTML5 is here: http://microformats.org/wiki/html5 and yes, more HTML5 examples are a good idea / would be welcome. |
| 20:07 | <Hixie> | tantek: does rel-license have a solution to the problem of setting the license on subparts of the page btw? e.g. on images without affecting the license of the whole page |
| 20:07 | <Philip`> | http://philip.html5.org/data/cc-errors.txt has some data on the CC-RDF-in-comments thing |
| 20:11 | <a-ja> | <img src='' rel="license"/> ??? |
| 20:11 | <a-ja> | nah |
| 20:12 | <tantek> | Hixie, rel-license itself does not, but Mike Linksvayer and I worked on developing a licensing microformat which would work for inclusion on parts of a page, e.g. for images. http://microformats.org/wiki/licensing |
| 20:12 | <tantek> | (Mike was former CTO of CC I believe) |
| 20:13 | <Hixie> | interesting |
| 20:14 | Philip` | remembers how Encarta would automatically add a copyright notice when you copied-and-pasted more than a few words into a text editor |
| 20:14 | <tantek> | Hixie, currently however, I am going to state that with respect to Creative Commons, this is more of a political problem rather than a technical problem. |
| 20:14 | <Hixie> | personally i think it's wrong to have copyright information be machine-readable at all |
| 20:14 | <tantek> | Ben Adida, is both CC's rep to the W3C and chairs the task force on RDFa : http://creativecommons.org/about/people/#13 |
| 20:15 | <Philip`> | When I'm scanning a load of .ttf files to find ones with licenses that allow modification, I really wish they contained machine-readable copyright information |
| 20:15 | <Hixie> | and i strongly object to creative commons' repeatedly causing license proliferation |
| 20:15 | <Hixie> | we have too many damn licenses as it is |
| 20:15 | <Philip`> | (Instead I've got a dozen regexps like qr/This (file|software|truetype software) is public domain\./ to find them) |
| 20:16 | <tantek> | Hixie, I tend to agree that license proliferation is a problem. |
| 20:17 | Philip` | 's regexp list includes qr/This font is inspired by Polish-Lithuanian Constitution of 3 Mai 1791 and is released to the Public Domain\./ |
| 20:18 | <tantek> | in conversations in the past, Ben Adida and I have chosen to agree to disagree with respect to namespaces. I think it is a fair characterization to say that he believes they are both essential and not a difficult hurdle for authors, and I believe they are undesirable, and sufficiently ugly/complex for vast majority of authors to reject any form of authoring that requires them. |
| 20:19 | <Hixie> | well i think it's clear where i stand on that particular issue |
| 20:19 | <tantek> | Thus I don't hold much hope for changing ccREL. |
| 20:20 | <tantek> | However I have hope that a licensing microformat will handling 80%+ of the use cases that ccREL claims to handle, and will be adopted by authors, blogging tools etc. and hopefully eventually search engines (as they adopted rel="license" when that was shown to be a success). |
| 20:20 | <tantek> | s/handling/handle |
| 20:28 | <tantek> | Hixie, note btw that ccREL stands for "Creative Commons Rights Expression Language" which, upon a brief reading of the vocabulary description ( http://creativecommons.org/ns - which itself does not validate - always makes me suspicious of anyone proposing new standards if they can't conform to current ones) seems to actually *encourage* more variants of licenses/rights/requirements. |
| 20:28 | <Hixie> | yes |
| 20:28 | <Hixie> | hence my comments above |
| 20:30 | <tantek> | yes, I think that attempting to capture/express that fine a detail is a big mistake |
| 20:30 | <Hixie> | yes, it's a terrible mistake |
| 20:30 | <Hixie> | and it doesn't work, either |
| 20:30 | <Hixie> | you can't properly encode legal practices in a finite vocabulary |
| 20:30 | <Hixie> | that's ridiculous |
| 20:31 | <tantek> | in fact, I'll go further than that, any attempt to express specific rights (other than just referring to a license URL) or any other kind of legality in supposedly machine readable/understandable form is a big mistake |
| 20:31 | <tantek> | Hixie, I agree, quite ridiculous. And undesirable. |
| 20:42 | tantek | is continuing the licensing microformat discussion in #microformats, for anyone who would like to view and or participate. |
| 22:52 | <Hixie> | Philip`: yt? |
| 22:52 | <Hixie> | Philip`: http://philip.html5.org/tests/canvas/suite/tests/2d.path.stroke.prune.arc.html |
| 22:52 | <Hixie> | Philip`: what would it take to change the spec to match what browsers do there? |
| 23:18 | <olliej> | Hixie++ |
| 23:19 | <cgriego> | I saw the <header> is now <hgroup> @whatwg tweet and I was all "nooo!" then I saw the new <header> tweet and I was all "whaa?" then I read the IRC log and I was like "oh, good stuff." |
| 23:23 | <hsivonen> | where should I look for offline cache manifest test cases? |
| 23:25 | <gavin_> | http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/ajax/offline/ ? |
| 23:27 | <hsivonen> | gavin_: thanks (I was looking for something that I can just browse to, though) |
| 23:31 | <Hixie> | cgriego: hehe |
| 23:31 | <Hixie> | olliej: what did i do to get incremented? :-) |
| 23:32 | <olliej> | Hixie: epic html5 work :D |
| 23:32 | <Hixie> | oh just the volume? :-) |
| 23:36 | <olliej> | Hixie: well and drawImage(<video>) |
| 23:36 | <Hixie> | ah |
| 23:39 | <Philip`> | Wasn't that months ago? |
| 23:39 | <Hixie> | yeah but i just sent mail about it again |
| 23:40 | <Philip`> | Oh |
| 23:40 | <Hixie> | so i'm willing to take double credit |
| 23:40 | <Hixie> | :-) |
| 23:41 | <hsivonen> | yay for hgroup! |
| 23:41 | <hsivonen> | Hixie: thanks |
| 23:42 | <hsivonen> | also, with the new <header>, HTML5 covers all of ARIA landmarks natively |
| 23:42 | <Hixie> | all of them? |
| 23:42 | <Hixie> | wow |
| 23:42 | <Hixie> | that's unexpectedly fortuitous |
| 23:44 | <hsivonen> | Hixie: yes, if you infer <form role=search> from <form> ... <input type=search> |
| 23:45 | <Hixie> | ew, they put the role no the <form>? that seems problematic |
| 23:45 | <Hixie> | surely you want it on the input control |