| 00:17 | <annevk42> | someone wrote an outline tool in JS: http://d.hatena.ne.jp/amachang/20090915/1252999677 |
| 00:18 | annevk42 | -> bed |
| 00:22 | <gsnedders> | Someone beat me to it. |
| 00:22 | <gsnedders> | Won't that cause an infinite loop in IE in some cases? |
| 00:23 | <gsnedders> | http://amachang.sakura.ne.jp/misc/outliner.js is the script itself |
| 00:42 | <heycam> | where is the part of the spec that defines conformance of foreign content? |
| 00:58 | <MikeSmith> | gsnedders, annevk42 - amachang is a serious force for good in the universe. he's one the of the Shibuya Javascript users group |
| 00:59 | <MikeSmith> | I saw him do a presentation at an event here last year or so, when John Resig came here to speak |
| 00:59 | <MikeSmith> | dude does some crazy stuff with javascript |
| 01:00 | <MikeSmith> | http://www.flickr.com/photos/takesako/1830101840/ |
| 01:07 | <heycam> | are all cases where serializing to XML is impossible without modifications (e.g. "--" in a Comment) non-conforming? |
| 01:09 | <Perceptes> | Question for you guys: I just learned earlier today that I've been incorrectly using the time element as block level. Is there a block level element that could be used semantically to refer to a timestamp without just resorting to a div? The context is here: http://www.jimmycuadra.com/blog/ I'm working on a new HTML5 version of this and the little calendars in the top right corner of each post are what I'm referring to. |
| 01:10 | <Hixie> | <p> ? |
| 01:10 | <Hixie> | or just don't use a block-level element :-) |
| 01:11 | <Hixie> | <header> <h1>...</h1> <p>by Jimmy</p> <time datetime=...>Aug 31</time> </header> |
| 01:11 | <Hixie> | that's valid |
| 01:12 | <Hixie> | it's a heading followed by two paragraphs |
| 01:12 | <Hixie> | there's kind of an "implied p" around the <time> |
| 01:13 | <Perceptes> | ok, thanks :) |
| 01:14 | <Hixie> | <p class="date"><time datetime=...>Aug 31</time></p> is fine too, if you prefer making the structure explicit |
| 01:14 | <Hixie> | <div> is ok too |
| 01:14 | <Perceptes> | yeah, I think that is what I'm gonna go with |
| 01:15 | <Hixie> | or you can put the <time> in the byline: <p>by Jimmy <span>at</span> <time ...>Aug 31</time></p> |
| 01:15 | <Hixie> | and display:none the span |
| 01:16 | <Perceptes> | how would I mark up the calendar graphic in that case? just div/p? |
| 01:16 | <Perceptes> | (the text in the calendar is not part of the image if that wasn't apparent) |
| 01:17 | <Hixie> | maybe using ::before, or a background on the <time> |
| 01:17 | <Hixie> | or ::outside, if the CSSWG has gotten around to speccing that |
| 01:17 | <MikeSmith> | heycam: about "--" in comments specifically, I think it's non-conforming in text/html too. About the general question, not sure |
| 01:20 | <heycam> | MikeSmith, ok |
| 01:25 | <Perceptes> | is it incorrect to have a <br> inside a phrasing element? (time in this case) |
| 01:28 | <Hixie> | it's almost always incorrect to use <br> |
| 01:28 | <Hixie> | the only exceptions i know of are postal addresses and poems |
| 01:31 | <Perceptes> | so then I run into a problem creating the line break between the month and the day if I try to make it one time element |
| 01:32 | <Perceptes> | and it wouldn't make sense to have two time elements since the whole thing represents one date |
| 01:34 | <Hixie> | put a span around the month |
| 01:34 | <Hixie> | and make it display:block |
| 01:35 | <Perceptes> | hmm, seems kind of hackish |
| 01:35 | <da3d> | You could just do time { white-space: pre; } or something, no extra elements then :) |
| 01:36 | <Perceptes> | that could work |
| 01:38 | <Hixie> | heh |
| 01:38 | <Hixie> | or you could just make it too narrow for more than one word :-) |
| 01:38 | <Hixie> | and have it automatically wrap |
| 01:38 | <Hixie> | this is the kind of thing for which CSS isn't really well suited yet |
| 01:38 | <Hixie> | what you really want is a mechanism to select a subrange and style that |
| 01:39 | <Perceptes> | yeah |
| 01:39 | <Hixie> | like ::subrange(from start to first space) |
| 01:39 | <Perceptes> | the white-space: pre trick seems to work well |
| 01:42 | <Perceptes> | html5.validator.nu doesn't recognize the pubdate attribute on the time element |
| 01:42 | <Hixie> | yeah pubdate="" on time is relatively new |
| 01:42 | <Hixie> | just ignore the error :-) |
| 01:42 | <Hixie> | it also doesn't recognise e.g. <p> in <caption>, which html5 uses |
| 01:43 | <Hixie> | so i get two validation errors each time i generate the spec :-) |
| 01:43 | <Perceptes> | I feel so elite using valid html5 that the validator doesn't even know about. ;P |
| 01:44 | <Hixie> | :-) |
| 01:56 | <Perceptes> | haha, it also says "alt" is not a valid attribute for <input>, then includes it in the list of acceptable attributes |
| 02:01 | <Hixie> | Perceptes: it's only valid for <input type=image>, is that the problem? |
| 02:01 | <Perceptes> | ahh, okay |
| 02:01 | <Perceptes> | I didn't catch that |
| 02:39 | <mpilgrim> | can someone PM me the twitter.com/WHATWG password? |
| 02:54 | <roc> | gah, people are still working on WebCGM? |
| 03:02 | <MikeSmith> | roc: I think airplane manufacturing and parts industry is still using it for something |
| 03:02 | <MikeSmith> | Boeing in particular, iirc |
| 03:02 | <roc> | sure, but on the *web*? |
| 03:03 | <otherarun> | Note that WebGL is around the corner: http://www.pcworld.com/article/171944/accelerated_3d_graphics_in_your_browser.html |
| 03:04 | <MikeSmith> | otherarun: would be really wonderful is some actual public information about the current state of the discussion were public |
| 03:05 | <MikeSmith> | or better yet, the current draft of the spec |
| 03:05 | <otherarun> | MikeSmith, *sigh. I'm working on it. Promise. |
| 03:06 | <otherarun> | I'm Chair of that WG. Not everyone is amenable to the level of openness that we'd like to see, but point well taken. |
| 03:22 | MikeSmith | is having a discussion about Google Wave in Japanese and finding as he has in past such discussions that the name "Wave" is not such an ideal name for a Web technology |
| 03:23 | <MikeSmith> | the pronuncation of the words "Wave" and "Web" seem to be easily confusable when transliterated phonetically into Japanese (even easily confusable by native speakers, it seems) |
| 03:28 | <MikeSmith> | it really comes down to the difference between "e" and "ē" |
| 03:53 | <boblet> | MikeSmith: I wonder how excited people will be by Cameron Adams’ Nov speech—are the ppl you’re talking to interested in it? |
| 03:55 | <MikeSmith> | boblet: everybody I talk to seems to be interested in it.. just waiting for more info and code to be made public |
| 03:56 | <boblet> | MikeSmith: I wonder if it’ll finally move Japan into UTF8-land for email |
| 03:56 | <boblet> | oh that’s right, mobile :| |
| 03:56 | <boblet> | har |
| 03:56 | <MikeSmith> | yep |
| 03:57 | <MikeSmith> | exactly what I was going to say |
| 03:57 | <MikeSmith> | the state of mobile e-mail clients on handsets in Japan is sad, sad joke |
| 03:57 | <MikeSmith> | the infrastructure is perfectly capable |
| 03:57 | <MikeSmith> | it's the crap mobile mail clients that are the problem |
| 03:57 | <MikeSmith> | most of which are made by the same vendor |
| 03:58 | <MikeSmith> | which vendor should be ashamed of itself for the mess they've helped to make |
| 03:58 | <boblet> | here’s hoping the iPhone will lead by example (am hoping that Safari and Opera Mobile will do the same for web browsing and kill iMode) |
| 03:59 | <boblet> | and carriers will demand better apps |
| 03:59 | <MikeSmith> | are there real native e-mail clients for the iPhone? |
| 03:59 | <boblet> | mail.app…? |
| 04:00 | <MikeSmith> | ah, OK |
| 04:00 | <MikeSmith> | I really need to get an iPhone |
| 04:00 | <MikeSmith> | and an Android handset |
| 04:00 | <MikeSmith> | and a Palm Pre |
| 04:00 | <boblet> | although Softbank’s imap setup is a joke (no emoji unless you send using their SMTP, although Gmail on iPhone sends/receives fine) |
| 04:01 | <MikeSmith> | ...and a new Au handset |
| 04:01 | <boblet> | MikeSmith: haha, at least they’ll be tax-deductible! |
| 04:01 | <MikeSmith> | boblet: I should personally refrain from commenting at all on Softbank |
| 04:02 | <MikeSmith> | I will say that I wish Softbank would focus more on providing competitive high-quality services |
| 04:03 | <MikeSmith> | boblet: anyway, are there any Japanese-language video presentations (or at least slides) about Google Wave that you know of? |
| 04:03 | <boblet> | very politicly worded |
| 04:04 | <boblet> | MikeSmith: not that I’ve seen, but I heard there was a Wave-related meetup in Kyoto recently, so I can ask if you want |
| 04:04 | <MikeSmith> | boblet: I guess we can ask the Google.jp folks |
| 04:04 | <MikeSmith> | maybe the will have something more to show publicly by time of the Oct. 1-3 event |
| 04:05 | <boblet> | MikeSmith: I’m half-expecting a little something on it during those events yeah |
| 04:05 | <MikeSmith> | yeah |
| 04:05 | <boblet> | at least a little marketing speil |
| 04:05 | <MikeSmith> | last I heard, September 30 was targeted to be a major milestone, will more info and maybe code release at that time |
| 04:06 | <MikeSmith> | R&D folks wants code, not just marketing speil |
| 04:11 | boblet | would like a beta invite :| |
| 04:23 | <boblet> | mpilgrim: thanks for http://blog.whatwg.org/this-week-in-html5-episode-35 it’s a great summary |
| 04:23 | <GPHemsley> | Hixie: What about <item> in place of <article>? |
| 04:24 | <GPHemsley> | (or anyone else, since Hixie's AFK) |
| 04:29 | <GPHemsley> | (gah, stupid list/Gmail making me not reply to the list...) |
| 04:30 | <GPHemsley> | Hixie: Apologies that you got two copies of that e-mail just now. |
| 04:31 | <GPHemsley> | oh... it needs to be approved... |
| 04:31 | <GPHemsley> | anyone care to do that for me? :) |
| 08:27 | <boblet> | later |
| 08:46 | Hixie | wonders where maciej is |
| 09:16 | <MikeSmith> | Hixie: "cook the copy pasta" is among your better ones |
| 09:16 | <MikeSmith> | as far a commit messages |
| 09:16 | <Hixie> | i love the term "copy pasta" |
| 09:16 | <Hixie> | don't get to use it much |
| 09:21 | <Lachy> | what does "copy pasta" mean? |
| 09:21 | <Lachy> | oh, is it like copy/paste error? |
| 09:21 | <Hixie> | it usually means a copy-paste spam attack |
| 09:21 | <Hixie> | but i use it to mean a copy-paste error |
| 09:23 | <MikeSmith> | Hixie: btw, fwiw, count me among those who think removing <dialog> is a good step.. but I think that one step forward, your <dt>+<dd>-in-figure-and-details experiment is at least two steps back |
| 09:23 | <Hixie> | heh |
| 09:23 | <Hixie> | why? |
| 09:23 | <MikeSmith> | that said, if it turns out that the authoring community seems to like it, great |
| 09:24 | <Hixie> | i mean, it's not my first choice (obviously), but it doesn't seem all that bad, especially for <details> |
| 09:24 | <Hixie> | it's a bit less perfect for <figure> |
| 09:26 | <Lachy> | I don't really like it for figure because it needs to have the extraneous <dd> element |
| 09:26 | <MikeSmith> | as I mentioned before I think it's suboptimal to have any element whose semantics change drastically based on what its parent element is |
| 09:26 | <Lachy> | I don't think that's a problem |
| 09:27 | <MikeSmith> | Lachy: why? |
| 09:27 | <Lachy> | why is it? |
| 09:27 | <MikeSmith> | why isn't it? |
| 09:27 | <hsivonen> | Lachy: the "extraneous" element is an awesome styling hook |
| 09:28 | <MikeSmith> | should we have lots of elements whose semantics change drastically based on what their parent element are? |
| 09:28 | <MikeSmith> | is that the best kind of language design to aim for? |
| 09:28 | <Hixie> | MikeSmith: i don't see why that would be a problem |
| 09:29 | <Lachy> | MikeSmith, doing it where it provides some benefits doesn't seem like a bad thing. |
| 09:30 | <MikeSmith> | Lachy: exactly. I realize there are tradeoffs in terms of backward compatibility, etc., but it's not clear this case is a net win |
| 09:31 | <MikeSmith> | it's not even clear, actually, that adding figure and details are a net win, for that matter |
| 09:31 | <Lachy> | besides, languages in general have many words that change meaning based on context, and that's no problem. I don't see why it's a problem for some limited cases in a markup language? |
| 09:31 | <MikeSmith> | the analogy to natural languages is not particularly relevant |
| 09:32 | <Hixie> | other than it being "suboptimal", are there any concrete problems it introduces? |
| 09:32 | <Hixie> | it seems theoretically sound -- the element is meaningless on its own anyway |
| 09:32 | <MikeSmith> | Hixie: confusion |
| 09:32 | <Hixie> | what confusion? |
| 09:32 | <Hixie> | i don't see how this is confusing |
| 09:33 | <Hixie> | is it confusing that different DOM nodes have members with the same name that do different things? |
| 09:33 | <Hixie> | e.g. window.item() and document.item() ? |
| 09:33 | <MikeSmith> | the blazingly obvious potential confusion that we used to have an element that meant one particular thing and that now means 3 different things |
| 09:34 | <MikeSmith> | Hixie: the entire DOM is confusing |
| 09:34 | <Hixie> | i honestly don't see how this would confuse people in practice |
| 09:34 | <Hixie> | it's not like people are like "I'm going to use the <dt> element!" |
| 09:34 | <Hixie> | they're more like "I'm going to use <dl>... that means I need a <dt> and a <dd>." |
| 09:36 | <Lachy> | they're not vastly different meanings. The dt is still the label and dd is still the content being labelled in all 3 cases. It's just different types of labels and content. |
| 09:36 | <Hixie> | that too |
| 09:37 | <Philip`> | Elements changing drastically based on their parent element seems bad for CSS, because people want to do "dd { font-weight: bold }" and don't understand more complex selectors like "dl > dd" |
| 09:37 | <Philip`> | which means they won't know how to style figure>dd differently from dl>dd, without just using class |
| 09:37 | <MikeSmith> | bingo |
| 09:37 | <hsivonen> | http://www.cssquirrel.com/2009/09/14/comic-update-the-whatwg-legion-of-doom/#comment-27140 |
| 09:38 | <Hixie> | Philip`: yeah, if the meaning changed radically, that could be a problem |
| 09:38 | <MikeSmith> | more complexity for authors in order to make things slightly easier for implementors |
| 09:39 | <hsivonen> | Hixie: what's the consumer use case for marking up IRC log timestamps as <time>? |
| 09:39 | <Philip`> | dt indenting is probably more of an issue, because you'd never want that to apply to figure>dt |
| 09:39 | <Philip`> | (compared to bolding dd, which is probably safe in all contexts) |
| 09:40 | <annevk2> | hsivonen, IRC mashups! |
| 09:40 | <hsivonen> | annevk2: without time zone? |
| 09:40 | <annevk2> | hsivonen, I imagine aggregated logs of #whatwg, #html-wg, #webapps so that I can read up on all three at once :) |
| 09:41 | <annevk2> | hsivonen, doesn't matter for these three, but otherwise you should probably have a time zone, yes |
| 09:46 | <hsivonen> | smells like write-only metadata |
| 09:46 | <hsivonen> | Philip`: I think you got dd and dt the wrong way round |
| 09:46 | <hsivonen> | dd and dt are so memorable |
| 09:47 | annevk2 | filed a bug on disabling the margin of <dd> within <figure> and <details> |
| 09:53 | <annevk2> | maybe we should give <article> some meaningless name, like <supersection> |
| 09:53 | <annevk2> | or we have <sec> and <secstandalone> |
| 09:54 | <annevk2> | in theory the majority of authors will not understand the name anyway |
| 09:54 | <annevk2> | and it's not like <p>, <dl>, <body>, etc. are very clear |
| 09:56 | <Hixie> | <post>, maybe |
| 09:56 | <Hixie> | i like <item> but it clashes with a lot of other things, like microdata and some ideas i had for data-*="" some time back |
| 09:56 | <Hixie> | so i don't know if we want to use <item> for this |
| 09:57 | <annevk2> | my initial thought was <item> too, fwiw |
| 09:58 | <annevk2> | what's the idea for data-*? |
| 09:59 | <Philip`> | hsivonen: That is quite possible |
| 09:59 | <hsivonen> | Hixie: with <post>, how do you make people use <post> for each blog comment |
| 10:00 | <Hixie> | annevk2: nothing very well formed |
| 10:00 | annevk2 | is not that fond of well-formed anyway |
| 10:00 | <annevk2> | :p |
| 10:00 | <Hixie> | :-P |
| 10:00 | <Hixie> | basically some of the same stuff that become microdata |
| 10:00 | <Hixie> | though in a very different form |
| 10:00 | <Hixie> | it may even have been in the spec back in 2004-5 or so |
| 10:01 | <Hixie> | hsivonen: do people not consider blog comments like forum posts? |
| 10:01 | <hsivonen> | Hixie: they may consider them to be different from the "post" |
| 10:02 | Philip` | wonders if we'll end up with a load of elements like code/samp/kbd/var, just for blogs rather than for technical documentation |
| 10:02 | <Philip`> | and in ten years nobody will have blogs any more and it'll just be a load of legacy cruft |
| 10:04 | <hsivonen> | Hixie: what's the consumer use case for <article> again? |
| 10:05 | <hsivonen> | Hixie: moving between major parts using AT/keyboard? |
| 10:05 | <Hixie> | hsivonen: styling the blog post containiner separately from the blog post subsections. |
| 10:05 | <Hixie> | possibly subscribing to html feeds rather than atom feeds |
| 10:06 | <Hixie> | one could imagine other uses, like sharing syndicatable content, but those are pie-in-the-sky |
| 10:07 | <Lachy> | what's the reason for wanting to rename article? |
| 10:08 | <Hixie> | if it could help convey its purpose, that might be one way to address recent purported confusion |
| 10:08 | <Hixie> | though frankly, it seems usually to used correctly to me |
| 10:09 | <Lachy> | I thought it was being used correctly. |
| 10:09 | <Lachy> | the confusion was over <section> |
| 10:11 | <Lachy> | I think people failed to realise how <article> and <section> were related to each other and how they should be used together |
| 10:11 | <Lachy> | maybe if it were <section type=article> people wouldn't have been confused |
| 10:12 | <Hixie> | the whole point here is to make it so people don't have to use classes |
| 10:13 | <Hixie> | not much point change <div class="post" to <section type="article">, it's like twice as long |
| 10:13 | <Hixie> | s/change/changing/ |
| 10:13 | <Hixie> | and add a > |
| 10:19 | <annevk2> | maybe <§> and <article> would do the trick |
| 10:19 | <hsivonen> | too bad we can't have <§> |
| 10:20 | <annevk2> | which reminds me, it might make sense to name it <sect> for consistency with the entity |
| 10:20 | <hsivonen> | an obscure HTML5 sect |
| 10:22 | <annevk2> | I didn't know about ⁂ |
| 10:24 | <beowulf> | asterism? |
| 10:25 | <beowulf> | hr = ⁂, no? |
| 10:27 | <jgraham_> | <sect> and <post> are both horrible imho |
| 10:31 | <annevk2> | jgraham_, prolly because your British |
| 10:32 | <jgraham_> | ? |
| 10:32 | <Lachy> | let's just leave <section> and <article> alone |
| 10:32 | <annevk2> | to me it's pretty much the same as what we have now :) |
| 10:33 | <jgraham_> | <post> is much worse than <article>. An <article> suggests a newspaper of magazine article whereas a <post> sounds purely blog centric |
| 10:33 | <jgraham_> | Doesn't atom use <entry>? |
| 10:33 | <hsivonen> | yes |
| 10:33 | <jgraham_> | Maybe we could use that... |
| 10:34 | <jgraham_> | (I don't know if it's better in terms of an english word but it might convey "individually syndicatable piece of content") |
| 10:34 | <annevk2> | and it's more clear that comments are entries than articles |
| 10:35 | <annevk2> | though like with all the others maybe it should also explain what it's not, e.g. each line of an IRC log is probably not usually an entry |
| 10:42 | <hsivonen> | http://blogs.msdn.com/xweb/archive/2009/09/03/free-internet-explorer-debugging-tool-microsoft-expression-web-superpreview-for-windows-internet-explorer.aspx |
| 10:43 | <hsivonen> | great synergies for unique authoring tool features and engine versioning from one vendor |
| 10:44 | <annevk2> | it's a great strategy; 1) become market leader 2) complicate your product by versioning 3) start selling tools that deal with the added complexity 4) profit! |
| 10:47 | <jgraham_> | I guess once you do 1) 4) can be achieved with many different combinations of 2) and 3) |
| 10:49 | <annevk2> | so maybe 2/3 should become the infamous ... |
| 10:50 | <adactio> | Apart from <article> containing an optional <time> element with a @pubdate attribute, what is the difference between <section> and <article>? |
| 10:50 | <Hixie> | adactio: difference from who's perspective? |
| 10:50 | <jgraham_> | adactio: They are semantically different |
| 10:51 | <adactio> | From an author's perspective. I understand the difference between <div> and <section>/<article> in that <div> isn't sectioning content. |
| 10:51 | <jgraham_> | Also, <article> correponds to a single feed entry (I guess) |
| 10:51 | <adactio> | jgraham: Is that the sole use case then? |
| 10:52 | <zcorpan> | <address> applies to nearest ancestor address or body |
| 10:52 | <Hixie> | adactio: <article> is intended to be as different from <section> as <div class="post"> is from <div class="section"> |
| 10:52 | <jgraham_> | adactio: an <article> is a piece of unique content. A <section> is a subpart of some larger entity (either the <body> or an <article>, typically) |
| 10:52 | <zcorpan> | <article> is like a nested <body> |
| 10:53 | <adactio> | jgraham: and yet <article>s could also be nested in a <section>. See the confusion? |
| 10:53 | <jgraham_> | So if I wrote a thesis in HTML it would be very long but would use <section> everywhere; it is a single continuous work |
| 10:53 | <adactio> | zcorpan: So is <section>. |
| 10:53 | <zcorpan> | adactio: no, not really |
| 10:53 | <jgraham_> | If I wrote a newspaper, each article would be an <article> |
| 10:53 | <adactio> | jgraham: unless it contained standalone content, in which case you should use <article> for those parts. |
| 10:53 | <annevk2> | the answers given so far do not really make it obvious why someone would use <article> to be honest |
| 10:54 | <adactio> | annevk2: that's what I mean. When smart people who should know this stuff can't explain it, that's very worrying. |
| 10:54 | Hixie | thought we had explained it fine :-) |
| 10:54 | <jgraham_> | adactio: <article> in <section> makes sense. Imagine a newspaper that divides up its page into sections for "sport", "fashion", "kittens" and so on. Each section can have several articles |
| 10:55 | Hixie | thinks he knows why adactio and annevk2 both have trouble understanding this |
| 10:55 | <Hixie> | neither of you have <div class="post">-like <div>s on your blogs! |
| 10:55 | <adactio> | jgraham_: yes, <article> in <section> makes as much sense as <section> in <article>. That's kinda the problem. |
| 10:55 | <jgraham_> | adactio: That's the nature of publishing |
| 10:55 | <Hixie> | adactio: <ol> in <ul> makes sense just like <ul> in <ol>, doesn't mean they're the same |
| 10:56 | <jgraham_> | There isn't one true heirachy that works for all kinds of content |
| 10:56 | <annevk2> | Hixie, heh |
| 10:56 | <zcorpan> | people should use divs more, then it'll all make sense |
| 10:56 | <Hixie> | most people do :-P |
| 10:57 | <zcorpan> | they can always use more |
| 10:57 | <Hixie> | if you don't have a <div class="post"> on your blog, then <article> isn't for you |
| 10:57 | <adactio> | Don't you think it's going to be a problem that, given a piece of content, one author may choose to mark it up one way (say a <section> with <article>s) and another author chooses to mark it up another way (say <article>s in a <section>) and both would be correct. |
| 10:57 | <annevk2> | I understand the distinction, I just don't see the big advantage in having <article> |
| 10:57 | <zcorpan> | divs are like violence |
| 10:57 | <Hixie> | annevk2: right, because you don't need it. there is no advantage to you. |
| 10:57 | <adactio> | Hixie: couldn't the same be said of <acronym> and <abbr>? |
| 10:58 | <jgraham_> | adactio: Do you have evidence that in the same situation two different authors would do different things? |
| 10:58 | <Hixie> | adactio: i don't think in general that it is a problem for there to be More Than One Way To Do It, but in the case of <section> and <article>, they aren't interchangeable. |
| 10:58 | <Hixie> | adactio: i don't see how one author would use <article> where another used <section> in a manner where they are both correct |
| 10:58 | <Hixie> | adactio: they have mutually exclusive roles |
| 10:58 | <adactio> | jgraham_: no firm evidence but I do have evidence of confusion amongst authors: http://adactio.com/journal/1607/ |
| 10:58 | <jgraham_> | (but in general I don;t think this is more of a problem here than anywhere else in html) |
| 10:59 | gsnedders | thinks we should just simplify everything by making <plaintext> the only conforming element |
| 10:59 | <Hixie> | adactio: that shows confusion over the definitions, which i've since fixed |
| 10:59 | <boblet> | adactio: that’s due more to the description though isn’t it? |
| 10:59 | <jgraham_> | adactio: That was a very nice study but it showed something totally different |
| 11:00 | <boblet> | for me a chunk of related content vs a chunk of related content _that can stand alone_ (eg in an RSS feed) is clear |
| 11:01 | boblet | needs to check what Hixie changed it to though |
| 11:01 | <Lachy> | Hixie, while it would be wrong to use <article> where <section> is appropriate, using <section> where <article> could be used, isn't that bad. |
| 11:01 | <beowulf> | gsnedders: i agree! though i suggested one for inline and one for block... |
| 11:01 | <Hixie> | Lachy: yeah, i guess i buy that |
| 11:02 | <Lachy> | Hixie, fwiw, in my article that I'm writing about sectioning, I start by teaching authors how to use <section> appropriately, to get the right outline, and then move on to replacing <section> elements with more specialised sectioning elements |
| 11:03 | <Hixie> | sensible |
| 11:03 | <Hixie> | lachy: though make sure you use <div> in the first bit also, e.g. around the header and footer, to show that <section> isn't just the new <div> |
| 11:03 | <zcorpan> | - where glyphs like 私 and 達 are anchored, and the bottom |
| 11:03 | <zcorpan> | + where glyphs like 私 and &#x9054; are anchored, and the bottom |
| 11:04 | <zcorpan> | Hixie: what happened there? |
| 11:04 | <Lachy> | Hixie, I'll show you what I've got so far |
| 11:04 | <Lachy> | one sec... |
| 11:04 | <boblet> | Hixie: new descriptions are clear for ppl who understand the distinction, but could each use a sentence describing the difference (similar to the one in <section> about diffs with <div> |
| 11:06 | <Lachy> | Hixie, and anyone else who wants to take a look http://lachy.id.au/temp/article/ - keep in mind, it's a work in progress |
| 11:07 | <Hixie> | boblet: yeah, good point. could you file a bug about that? (just copy the above into the input box on the spec) |
| 11:07 | <Hixie> | zcorpan: oops. will fix in a sec. |
| 11:08 | <Philip`> | gsnedders: Making only the <plaintext> element conforming would be no good, because of the implied <html>/<head>/<body> elements when you use it |
| 11:08 | <Hixie> | zcorpan: (probably over-eager search/replace) |
| 11:08 | <adactio> | Here are four pieces of markup: http://pastebin.com/d4501b0f1 Are any of them wrong? |
| 11:08 | <Hixie> | Lachy: encoding issues with that |
| 11:09 | <boblet> | Hixie: sure |
| 11:10 | <Hixie> | adactio: the first would make sense if you were writing a blog called DOM scripting and had it on a page that had lots of other things on it, like a portal might |
| 11:10 | <annevk2> | adactio, pretty sure it depends on "intent"... |
| 11:10 | <Hixie> | adactio: the second makes sense if you wrote a single blog post called "DOM Scripting" which had two subsections |
| 11:10 | <Hixie> | adactio: the third makes sense if you're writing a book and have a chapter called "DOM Scripting" which has two subsections |
| 11:11 | <Lachy> | Hixie, fixed it |
| 11:11 | <Hixie> | adactio: the fourth makes sense if you wrote a blog post "DOM Scripting" and two people had posted blog comments on it, called "JavaScript" and "The DOM" |
| 11:11 | <boblet> | Hixie: I don’t know if you want to go this far but check “New sectioning elements in a nutshell” list here: http://boblet.tumblr.com/post/141239118/html5-structure4 |
| 11:11 | <boblet> | (will add that link to report) |
| 11:11 | <zcorpan> | Lachy: from not reading the article very carefully and looking at the examples, i get the impression that i should replace all my divs with section |
| 11:11 | <Lachy> | it seems my text editor didn't have the default set to UTF-8 on that computer |
| 11:11 | <Hixie> | boblet: thanks, i'll take a closer look when addressing the bug |
| 11:12 | <Hixie> | Lachy: works now. reading... |
| 11:12 | <Lachy> | zcorpan, yeah, I still need to address that issue. |
| 11:12 | <Lachy> | That's will be part of the subsection currently titled *Wrappers* (though it may be renamed to something better) |
| 11:12 | <Hixie> | Lachy: "h1 for second level headings" should be h2 |
| 11:12 | <Lachy> | oops |
| 11:12 | <zcorpan> | Lachy: hint: never say what people should not do, only tell them what they should do |
| 11:12 | <adactio> | Hixie: so the use cases are relatively clear as long as you're writing a blog or a book. For anything else (say, a web page on a web site) you get doubt and uncertainty. |
| 11:13 | <boblet> | I think that makes the difference clear in author-comprehendible language |
| 11:14 | <Lachy> | zcorpan, I disagree. It's appropriate to place limits on how far they should go after telling them everything they should do |
| 11:14 | <Hixie> | adactio: why? |
| 11:14 | <Lachy> | but, I do need to rephrase that last section |
| 11:14 | <zcorpan> | Lachy: telling them to place limits is telling what to do :) |
| 11:14 | <Hixie> | adactio: do you have an example of a page on which you're not sure what should be an article and what should be a section? |
| 11:14 | <adactio> | Hixie: because the explanations you gave rely on the author either writing a blog or a book. |
| 11:15 | <workmad3> | human nature is to do something once you've been told you shouldn't (e.g. touching something with a 'wet paint' sign on it) |
| 11:15 | <boblet> | Lachy: btw +1 for starting with section then changing to article. I’d add div to the list though ;-) |
| 11:16 | <Hixie> | Lachy: i think you need to make it clear at "And then repeat the process with all other similar div elements" that that doesn't mean all <div> elements, only those with headings |
| 11:16 | <Hixie> | adactio: those were just examples to try to convey the difference |
| 11:16 | <Hixie> | adactio: they weren't the only possible situations in which you'd write such markup, just the clearest examples i could think of |
| 11:16 | <adactio> | Hixie: but I have yet to the difference conveyed without relying on the *specific* examples of blog posts. |
| 11:17 | <Hixie> | adactio: oh you want me to describe the difference in abstract terms? |
| 11:17 | jgraham_ | has frequently used newspaper articles |
| 11:17 | <Hixie> | adactio: sorry, i thought you wanted examples because the spec already does the abstract terms thing so i figured examples were the way to explain it :-) |
| 11:17 | <adactio> | Hixie: well, that's what the spec currently attempts to do and IMHO doesn't succeed. |
| 11:18 | <jgraham_> | adactio: It seems like a reasonable litmus test is "could this be an independent item in an aggregator" |
| 11:18 | <Hixie> | adactio: in abstract terms, "section" is any block of content that forms one unit, and "article" is any block of content that forms one self-contained unit. |
| 11:19 | <adactio> | Hixie: so the difference is between "one unit" and "one self-contained unit". |
| 11:19 | <adactio> | They sound *very* close in meaning. |
| 11:19 | <Dashiva> | A section is part of a whole, an article is a whole. |
| 11:19 | <Hixie> | adactio: yes, "article", "nav" and "aside" are subsets of "section" |
| 11:20 | <adactio> | Dashiva: but an <article> can also be part of a bigger whole (e.g. comments on a blog). |
| 11:20 | <Hixie> | adactio: "aside" is any block of content that forms one unit related but separate from its container |
| 11:20 | <workmad3> | Dashiva: I see it the other way around... a section is a whole, but it can be split up, an article can't reasonably be split up |
| 11:20 | <Hixie> | adactio: "nav" is any block of content that forms one unit about navigation |
| 11:20 | <Dashiva> | adactio: But it's still a unit in itself in that case |
| 11:21 | <adactio> | workmad3: but you can nest articles within articles so the containing article can therefore be split up. |
| 11:21 | <adactio> | Dashiva: but is it self-contained? |
| 11:21 | <Hixie> | adactio: (though in general usage, i would recommend using <section> only when the others don't apply, e.g. as you would use <em> instead of <i>, since it makes styling easier) |
| 11:21 | <Hixie> | (i mean, there's nothing _wrong_ with using <i> everywhere you want italics, it's just easier to style if you use <em>, <cite>, <var> etc in preference to <i>) |
| 11:22 | <Dashiva> | adactio: It is if it is |
| 11:22 | <Hixie> | (where appropriate) |
| 11:22 | <workmad3> | adactio, would the contained articles necesarilly make sense without the container though? |
| 11:22 | <Dashiva> | That's the point of the element, isn't it? If it's self-contained it's an article, otherwise it isn't. Makes little sense to talk about non-self-contained articles |
| 11:22 | <adactio> | workmad3: blog comments. The spec recommends wrapping them in <article>. Do they stand alone without the containing article (i.e. the blog post). |
| 11:22 | <Hixie> | adactio: nested articles aren't really part of their container, they're just "attached" to their container. blog comments aren't part of the blog post, they're just attached to the blog post. |
| 11:22 | <jgraham_> | adactio: http://intertwingly.net/blog/comments.html |
| 11:22 | <zcorpan> | Hixie: then the spec shouldn't say i should only be used as a last resort |
| 11:23 | <zcorpan> | Hixie: and div and b |
| 11:23 | <jgraham_> | suggests that people are happy with comments as self-contained units |
| 11:23 | <adactio> | Hixie: then is a blog comment really "a self-contained unit" or is it really "a unit"? |
| 11:23 | <Hixie> | adactio: the spec says a blog comment is an example of a self-contained unit |
| 11:23 | <adactio> | jgraham_: really? you think a blog comment makes sense out of context? |
| 11:24 | <adactio> | Hixie: yes, I know that the spec says that. I'm questioning the veracity of it |
| 11:24 | <Hixie> | another way of looking at it would be this: |
| 11:24 | <Hixie> | <Article> makes sense for anything you'd give a permalink to |
| 11:24 | <Hixie> | though i guess some people go crazy and permalink every paragraph |
| 11:25 | <adactio> | Hixie: e.g. http://www.tbray.org/ongoing/When/200x/2009/09/14/Copyright-Consultation |
| 11:25 | <Dashiva> | A stable link isn't necessarily a permalink |
| 11:25 | <jgraham_> | adactio: I'm suggesting that people already extract comments fom their original context |
| 11:25 | <jgraham_> | http://firehose.diveintomark.org/ |
| 11:26 | <Hixie> | adactio: yeah that page is a good example. The things with [link]s are <article>s, the things with the pilcrows are paragraphs. |
| 11:26 | <Hixie> | adactio: (and the whole page of course has an implied [link] which isn't shown since it would just point to itself) |
| 11:26 | <adactio> | So when an author needs to decide between using <section> and using <article>, they need to decide if the content is "a unit" or "a self-contained unit". Sounds an awful lot like arguing about what the definition of is is. |
| 11:27 | <Hixie> | adactio: they have to make the same choice when deciding what to syndicate |
| 11:27 | <Hixie> | adactio: do you syndicate subsections of your blog posts? |
| 11:27 | <Lachy> | Hixie, yeah, I was trying to find a way to say that, while still making authors think about it for themselves, rather than just spoon feeding them the answer to everything |
| 11:27 | <adactio> | Whatever decision an author makes, it will be "true" in a Kenobian sense i.e. "from a certain point of view". |
| 11:27 | <adactio> | Hixie: is there any way to talk about <article> vs. <section> without it always coming back to blogs? |
| 11:28 | <workmad3> | I'm personally would probably avoid nesting <article> in <article>... and a blog post with comments as articles I'd probably wrap the entire thing up in a section so there wasn't any article nesting |
| 11:28 | <jgraham_> | http://www.zeldman.com/comments/feed/ |
| 11:28 | <workmad3> | s/I'm/I |
| 11:28 | jgraham_ | will stop now |
| 11:29 | <Hixie> | Lachy: (also, as a style note, i wouldn't say "there's also X, we'll look at this later", since without that sentence the reader doesn't know X exists, and telling him it does doesn't really help at that point; if it did you'd explain it then, not later.) |
| 11:29 | <Hixie> | adactio: not only blogs are syndicated |
| 11:29 | <Lachy> | Hixie, but, with the use of the outliner tool, I'm hoping authors will check their results and see their mistakes if they do naively change all divs to sections |
| 11:29 | <Hixie> | adactio: consider reddit, say. Comments are <article>s |
| 11:29 | <Hixie> | adactio: or a forum. each post is an <article>. |
| 11:30 | <Hixie> | adactio: i just like talking about concrete things because then it's easier for me to work out what we're talking about |
| 11:30 | <Hixie> | Lachy: hopefully! |
| 11:30 | <adactio> | But on a news site, a list of articles (containing the headline, and one line of text with a link to the complete article) isn't an <article> because it isn't self-contained. |
| 11:31 | <Hixie> | yeah, it's probably a <nav> or a <section> |
| 11:31 | <adactio> | Hixie: and yet, many news sites syndicate their content in an RSS feed of items with the headline, one line of text, and a link to the complete article. |
| 11:31 | <Hixie> | on cnn.com the "Yale worker" part could be an <article> (albeit an incomplete one), the Latest News would be a <section> or <nav> |
| 11:32 | <workmad3> | adactio, articles are items that could be syndicated but that doesn't mean that the complete article is what appears in the syndication (unless I'm missing something somewhere) |
| 11:32 | <Hixie> | adactio: the "Video: island ferry", "Voice chat on Facebook", "Talking about depression" bits would probably deserve <article>s |
| 11:32 | <Hixie> | adactio: which i believe matches what you say their feed might contain |
| 11:33 | <Hixie> | adactio: clearly when people syndicate the equivalent of a one-line <li>, it might be a bit heavy-duty to use an <article> for it |
| 11:33 | <adactio> | Hixie: but their list of articles (titles and links) also matches what their feed might contain. |
| 11:34 | <Hixie> | adactio: yeah, such near-useless feeds aren't a good match for what html5 is trying to describe |
| 11:34 | <workmad3> | but it isn't a list of articles. It's a list of links to articles |
| 11:34 | <adactio> | workmad3: that describes many RSS feeds. |
| 11:35 | <workmad3> | yup |
| 11:36 | <Hixie> | <article>s are for wrapping content. obviously something that is syndicated without content (such as a single link) doesn't match <article>. |
| 11:36 | <Hixie> | I'm not saying everything that is syndicated is an <article>, I'm saying that sections that are syndicated are <article>s |
| 11:36 | <Hixie> | does that make sense? |
| 11:38 | <adactio> | Hixie: it does make sense but it is *very* hard to explain ...which worries me. |
| 11:38 | <Hixie> | i really don't understand why it's hard to explain |
| 11:38 | <Hixie> | it seems pretty obvious to me |
| 11:38 | <adactio> | Some uses are clear (e.g. blog posts), some are much fuzzier (e.g. an FAQ Q&A). |
| 11:39 | <Hixie> | a FAQ Q&A? |
| 11:39 | <Hixie> | what are you syndicating in a FAQ Q&A? |
| 11:40 | <adactio> | Hixie: I would permalink it. It stands alone. |
| 11:40 | <Hixie> | zcorpan: I can't find the & think you mentioned. |
| 11:40 | <workmad3> | I think I see adactio's point... it's possible to explain it (and some people have a good clear picture in their head of the differences) but a lot of the potential audience for HTML5 aren't going to care about the 5 page document describing exactly what it is and want a one-line explanation that makes sense |
| 11:40 | <adactio> | Hixie: e.g. http://clearleft.com/does/speak/ |
| 11:41 | <Hixie> | adactio: when in doubt, don't use <article> |
| 11:41 | <Hixie> | adactio: the permalink thing was a bad guideline, i think |
| 11:41 | <adactio> | workmad3: Right. Most HTML elements can be explained pretty simply. <article> can be explained, but not pretty simply. |
| 11:41 | <Hixie> | i think the one line answer is "Use <article> instead of <section> if you would syndicate it." |
| 11:41 | <adactio> | Hixie: but on that page, I would mark up those three questions as articles (regardless of permalink) as they seem to satisfy the standalone criteria. |
| 11:42 | <workmad3> | in a way, the name is a bit too specific for a general concept... people have a certain idea in their head of what an article is |
| 11:42 | <adactio> | Hixie: that "instead of <section>" part is IMHO crucial and should appear in both parts of the spec (section and article). |
| 11:43 | <jgraham_> | adactio: THose are pretty clearly <section>s I think. The bits under it describing the conferences could be <article>s though |
| 11:43 | <adactio> | jgraham_: they may be <section>s but I don't think they're "pretty clearly" <section>s. |
| 11:43 | <beowulf> | explaining article is not the difficult part, is it? I thought the difficult part was deciding if your content should use it, and that difficulty exists with a lot of content types, no? |
| 11:44 | <Hixie> | adactio: i removed mention of sections in the <Article> section because i think it's what led to the confusion in your study |
| 11:44 | <jgraham_> | adactio: I can't work out how an individual entry in a Q&A could be regarded as an <article> |
| 11:45 | <adactio> | Hixie: but I don't think it's possible to talk about one without mentioning the other ...precisely because their semantics are so close (the difference between them is a subjective decision on what qualifies as "standalone"). |
| 11:45 | <workmad3> | jgraham_: how about in a QA column on a newspaper site? Would the question followed by the answer be an article? |
| 11:45 | <adactio> | jgraham: it stands alone. |
| 11:46 | <Hixie> | i've added a note to both the <section> and <article> sections |
| 11:46 | <adactio> | Here's an example of an article i.e. syndicated content (with a permalink): http://twitter.com/Hixie/status/3994558789 but it makes no sense out of context (much like a comment on a blog post). |
| 11:47 | <jgraham_> | adactio: I think I must be misunderstanding what you are talking about. Maybe you mean the whole Q&A section, rather than the individual questions? |
| 11:47 | <Hixie> | adactio: someone clearly thought it made sense out of context, otherwise it wouldn't be shown on a page of its own |
| 11:48 | <adactio> | jgraham_: no, I mean a question and an answer. The question is the header. Together, they form a standalone piece of content. |
| 11:48 | <workmad3> | it's a 'word of wisdow' sort of thing... context is required but feel free to supply your own ;) |
| 11:48 | <workmad3> | *wisdom |
| 11:48 | <adactio> | Hixie: right, so it's all down to interpretation which can vary wildly. |
| 11:48 | <Hixie> | welcome to html |
| 11:49 | <Hixie> | what in html _isn't_ down to interpretation? |
| 11:49 | <Hixie> | people argue about whether things are lists or not |
| 11:49 | <adactio> | jgraham_: here is an FAQ Q&A, complete with permalink: http://wiki.whatwg.org/wiki/FAQ#How_does_the_WHATWG_work.3F |
| 11:49 | <Hixie> | doesn't mean the spec is wrong to have an <ol> element :-) |
| 11:49 | <adactio> | Hixie: yes, but we don't want to maximise those areas of confusion, do we? |
| 11:49 | <jgraham_> | adactio: In your example the questions don't make sense without the other questions! |
| 11:49 | <adactio> | jgraham_: nonsense, it stands alone. |
| 11:50 | <jgraham_> | adactio: "But wait, I had a particular person in mind!" |
| 11:50 | <jgraham_> | That makes no sense without the previous question |
| 11:50 | <adactio> | jgraham_: not that, this example: http://wiki.whatwg.org/wiki/FAQ#How_does_the_WHATWG_work.3F |
| 11:50 | <Hixie> | adactio: we're not maximising the area of confusion, the spec is incredibly detailed and has more examples and notes and explanatory text than a school textbook |
| 11:50 | <da3d> | adactio: FAQs often contain questions that reference earlier questions in the FAQ, or follow-up questions... |
| 11:50 | <adactio> | da3d: http://wiki.whatwg.org/wiki/FAQ#How_does_the_WHATWG_work.3F |
| 11:50 | <annevk2> | adactio, not all FAQ entries there are standalone, e.g. some say "Also see HTML5 feature proposals below." |
| 11:50 | <adactio> | da3d: so do blog comments. |
| 11:51 | <annevk2> | fair point |
| 11:51 | <adactio> | annevk2: not blog comments are standalone. |
| 11:51 | <adactio> | Not all syndicated content is standalone e.g. twitter messages. |
| 11:51 | <jgraham_> | adactio: I would just use <section> for a FAQ. I regard it as a single entity that has been divided into sections, in the same way that a thesis is, even though various parts may work on their own |
| 11:52 | <adactio> | jgraham_: and I might use <article>. And you'd be right. And I'd be right. |
| 11:52 | <da3d> | adactio: well, I wouldn't really mark up blog comments as a bunch of <article>s :p |
| 11:52 | <adactio> | da3d: that's what the spec says you should do. |
| 11:52 | <workmad3> | it's an example that the spec suggests though |
| 11:52 | <annevk2> | da3d, that's what HTML5 says |
| 11:53 | <adactio> | The prosecution rests. |
| 11:53 | <workmad3> | I'd also disagree with it, but there isn't really a suitable alternative |
| 11:53 | <Hixie> | adactio: i don't see any way to consider a section of the whatwg faq as an article |
| 11:53 | <da3d> | I don't agree with everything the spec says :) |
| 11:53 | <workmad3> | at least not a suitable alternative with semantic meaning :) |
| 11:53 | <Hixie> | adactio: you might as well say a random paragraph is a standalone section because it happens to be a paragraph you can copy and paste separately |
| 11:53 | <adactio> | Hixie: it satisfies the criteria of being a standalone piece of content that would be given a permalink. |
| 11:54 | <Hixie> | adactio: the spec doesn't mention permalinks |
| 11:54 | <Hixie> | and i've already said permalinks are a bad guideline |
| 11:54 | <adactio> | Hixie: If the paragraph stands alone, then it *could* be an <article>. It all depends on the content ...on whether it's "a unit" or "a standalone unit" |
| 11:56 | <adactio> | So when I think I've found a non-blog use case that satisfies the criteria of <article> ( http://wiki.whatwg.org/wiki/FAQ#How_does_the_WHATWG_work.3F ), my interpretation is shaky. I think this will be true of a any non-blog usage. |
| 11:57 | Hixie | rewrites the definition of <article> in the spec based on this discussion |
| 11:57 | <Hixie> | hold on |
| 11:57 | <da3d> | For that FAQ, I'd make the entire FAQ an <article> and use <section> for each subsection of it... |
| 11:57 | <Hixie> | da3d: that'd be right |
| 11:58 | annevk2 | would use a <dl> for the entire thing |
| 11:58 | workmad3 | would make the entire thing out of <div>s just for fun |
| 11:58 | <annevk2> | way too many bytes with <article> and <section> :p |
| 11:59 | <adactio> | How does the FAQ example I've given not satisfy the criteria of being an article? "a self-contained composition that forms an independent part of a document, page, application, or site." "An article element is "independent" in the sense that its contents could stand alone" |
| 11:59 | <da3d> | What, 1 article and 8 sections is too much? :p |
| 11:59 | <Hixie> | adactio: hold on, i'm rewriting it |
| 11:59 | <Hixie> | ok, new definition: |
| 12:00 | <Hixie> | The article element represents a component of a page that consists of a self-contained composition that forms an independent part of a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content. |
| 12:01 | <adactio> | So that still satisfies this use case: http://wiki.whatwg.org/wiki/FAQ#How_does_the_WHATWG_work.3F |
| 12:01 | <Hixie> | i should add a usage summary section to the section section like i have on the phrasing elements section |
| 12:01 | <Hixie> | adactio: that question is not intended to be independently distributable or reusable, e.g. in syndication. |
| 12:01 | <Hixie> | it's not even got it's own page |
| 12:02 | <adactio> | Hixie: many blog posts don't have their own page (they have permalinks on a larger page). Besides, the spec doesn't say an article needs its own *page* (it doesn't even say an article needs its own URL). |
| 12:02 | <Hixie> | adactio: sure. but the point is that question is not intended to be independently distributable or reusable, e.g. in syndication. |
| 12:03 | <workmad3> | Hixie: an article is something that could conceivably have it's own page then? |
| 12:03 | <adactio> | So is the time-senstive nature of the content the crucial deciding factor when marking something up as an article? |
| 12:03 | <adactio> | And why wouldn't you provide an RSS feed of FAQs? |
| 12:03 | <Hixie> | workmad3: while it is often conceivable that an article would have its own page, that isn't part of the definition. |
| 12:04 | <workmad3> | just trying to get the new definition straight in my mind ;) |
| 12:04 | <Hixie> | adactio: i don't see anything about time-sensitiveness in the definition, so no, it is not a deciding factor. |
| 12:05 | <workmad3> | adactio, I think now if you fancy syndicating your FAQ then go ahead and articleise it too :) |
| 12:05 | <adactio> | Hixie: Then the deciding factor is "would I distribute this?" You wouldn't distribute an FAQ. I would. You're right. I'm right. |
| 12:05 | <Hixie> | adactio: if you felt like you should syndicate your questions, then sure, go ahead and use <article> for them. :-) |
| 12:05 | <Hixie> | adactio: i wouldn't independently distribute each question of the WHATWG FAQ |
| 12:06 | <Hixie> | adactio: i think the questions that are on Google's help page are <article>s, because they _are_ independently distributed. |
| 12:06 | <Hixie> | adactio: so it's not "should FAQs use <article>" but "should this FAQ use <article>" |
| 12:06 | <adactio> | Hixie: then the criteria is not "*would* I distribute this?", it's "*am* I distributing this?" |
| 12:06 | <Hixie> | adactio: just like it's not "should FAQs use RSS" but "should this FAQ use RSS" |
| 12:06 | <Hixie> | adactio: no, i think "would" is accurate here |
| 12:07 | <da3d> | I don't see how syndicating something in a feed necessarily leads to the conclusion that it should be an <article>. |
| 12:07 | <workmad3> | I think the new definition matches my mental model of an article at least (in terms of printed articles anyway)... an FAQ in it's entirety probably should be an article (it's standalone, it's intended for dissemination in such a form, etc) but the individual questions aren't really something most people would pull out and disseminate on their own |
| 12:08 | <workmad3> | even if you were pointing someone to a particular question, you'd tend to give them a link to the FAQ and then point them to a specific question in it (at least that's how I tend to use them) |
| 12:09 | <adactio> | Okay. It looks like the definition of <article> maps 100% to the hAtom microformat, so this list of hAtom examples should serve as a list of things that should be marked up as <article>s: http://microformats.org/wiki/hatom-examples-in-wild |
| 12:09 | <remysharp> | that new definition also includes "interactive widgets" which wouldn't typically constitute "content" - which seems confusing |
| 12:10 | <Hixie> | remysharp: an example of that would be the widgets on an iGoogle page -- they're <article>s, in that it makes sense to distribute them separately independent of each other |
| 12:11 | <remysharp> | but article in both the spec and the typical sense of the word, implies actual content - |
| 12:11 | <remysharp> | which is why including interactive widgets throws me off when I read that definition |
| 12:11 | <Hixie> | what do you mean by "Content"? |
| 12:11 | <Hixie> | is an e-mail widget not content? |
| 12:12 | <remysharp> | what's an email widget - off the top of my head, something that emails something to someone |
| 12:12 | <remysharp> | so no, I don't see that as content |
| 12:12 | <Hixie> | is GMail "content"? |
| 12:12 | <remysharp> | application |
| 12:12 | <Hixie> | HTML5 doesn't draw a distinction |
| 12:12 | <remysharp> | the email itself is the content |
| 12:12 | <Hixie> | is Amazon content? |
| 12:12 | <remysharp> | web site |
| 12:12 | <Hixie> | is the Google home page content? Is the search results page content? |
| 12:12 | <remysharp> | the reviews have content |
| 12:12 | <Hixie> | these are all "content" in the HTML5 sense |
| 12:13 | <Hixie> | "document" and "application" are the same thing, and are both "content" |
| 12:14 | <remysharp> | I'm coming from the layman/dev point of view, when I read your definition above, it's clear how I use article, up to the point in which interactive stuff is added. Content to me, your average joe author, is stuff I can read or interpret (images, etc) (prob not the best definition in the world, but you'll forgive me) |
| 12:15 | <Hixie> | not sure what i can do about that |
| 12:15 | <Hixie> | it's why i included the explicit mention of widgets |
| 12:16 | <adactio> | Content is stuff that's likely to be syndicated. Applications aren't, though they can be reused ...which is also mentioned in the spec for <article> ...but that does mean the question "would I syndicate this?" isn't enough of a criteria in deciding when to use <article>. |
| 12:17 | <adactio> | I wouldn't put a widget in an RSS feed ...that would be as crazy as putting FAQs in an RSS feed. ;-) |
| 12:17 | <Hixie> | right, that's why i said "distibuted or reused" |
| 12:17 | <Lachy> | syndication isn't a criteria. It's an example of something it could be used for, for a subset of the possible use cases |
| 12:17 | <remysharp> | equally I would never imagine to put a advanced form search in an article element either. |
| 12:20 | <adactio> | Then if the criteria is merely "reuse" rather than "syndication", anything that could be quoted in another context (e.g. on someone's blog) could be an article. And so, every paragraph on Tim Bray's blog could indeed be an <article>. Every paragraph can be reused. |
| 12:20 | <Hixie> | what word would be better? |
| 12:21 | <Hixie> | assuming you do understand what i actually mean it to say |
| 12:21 | <da3d> | Quotes aren't really stand-alone content imo |
| 12:22 | <adactio> | I'm suggesting that criteria of potential reuse isn't a strong enough reason to have a separate element. An <article> is, to all intents and purposes, a <section>. |
| 12:22 | <adactio> | da3d: the crucial part there being "imo" |
| 12:23 | <Hixie> | there are several use cases here, but i definitely think they justify having an element separate from <section> |
| 12:23 | <Hixie> | primarily: |
| 12:23 | <Hixie> | replacing <div class="post"> so that you don't need to use classes for marking up blog posts |
| 12:23 | <Hixie> | enabling trivial conversion of html to atom for syndication |
| 12:24 | <Hixie> | and making it easier to navigate a page that has multiple articles when using accessibility tools |
| 12:25 | <adactio> | Every one of those use cases could be solved with <section> (for the conversion for syndication, the current usage of <time @pupdate> would need to be be moved from <article> to <section>). |
| 12:25 | <Hixie> | how could you distinguish a subsection from a blog post? |
| 12:25 | <jgraham_> | adactio: How would you decide which <section>s are different <atom:entry>s |
| 12:25 | <da3d> | adactio: "imo" is just pure redundancy, actually :) |
| 12:26 | <adactio> | Hixie: the presence of <time @pubdate> |
| 12:26 | <adactio> | jgraham_: using <time @pubdate> |
| 12:27 | <Hixie> | adactio: how exactly do you select a <section> from CSS based on it containing a <time>? |
| 12:27 | <Hixie> | adactio: and what if there is no pubdate, or if the pubdate is only mentioned in a subsection? |
| 12:27 | <Lachy> | adactio, quotes aren't independent pieces of content. They are fragments of the whole (ignoring the rare case where something is quoted in its entirety) |
| 12:27 | <adactio> | Hixie: none of your use cases mentioned styling. |
| 12:28 | <adactio> | Hixie: if there is no pubdate, would it be distributed? |
| 12:28 | <jgraham_> | FWIW I think the "but a quote is reuse" argument is very weak |
| 12:28 | <Hixie> | adactio: "replacing <div class="post"> so that you don't need to use classes for marking up blog posts" |
| 12:28 | <adactio> | Lachy: IYHO. |
| 12:28 | <adactio> | Hixie: <section> |
| 12:28 | <Hixie> | adactio: FAQs don't have pubdates, and you said they could be distibuted |
| 12:28 | <Hixie> | adactio: how do i style my blog post separate from the subsections of my blog post? |
| 12:28 | <adactio> | Hixie: and you said they shouldn't. |
| 12:29 | <Hixie> | adactio: no, i said i wouldn't |
| 12:29 | <Hixie> | adactio: but that it would be fine to do so |
| 12:29 | <adactio> | Hixie: so is the issue of styling the crucial question here, rather than the three use cases you mentioned? |
| 12:29 | <Lachy> | picking the presence of absense of any particular markup, such as a pubdate, as a criteria for using <article> is a bad idea |
| 12:29 | <Hixie> | adactio: the first use case i mentioned is all about styling |
| 12:29 | <jgraham_> | (actually Hixie gave an example of where they would be) |
| 12:30 | <adactio> | Hixie: no, the first use case you gave was semantic demarcation. Unless you were conflating usage of the class attribute with CSS class selectors. |
| 12:31 | <Hixie> | adactio: ok, replace the first use case with "replacing <div class="post"> so that you don't need to use classes for styling blog posts" |
| 12:31 | <Hixie> | i should not have said "marking up" |
| 12:32 | <adactio> | IF an <article> is a specialised kind of <section> AND some mechanism is required to indicate "this content could be distributed" AND some mechanism is required to style articles differently THEN why not use an @article attribute on a <summary> element? |
| 12:32 | <Lachy> | adactio, convenience |
| 12:33 | <da3d> | Well you could use the > selector to avoid to classes, but it's kind of a pita compared to just article {}. |
| 12:33 | <adactio> | Lachy: does that apply in general? i.e. Don't create new attributes when you can create a new element. |
| 12:33 | <Lachy> | <article> is shorter than <section type=article>, and easier to style without attribute selectors that some browsers don't suppor |
| 12:34 | <Hixie> | adactio: if the idea is to make <div class="post"> more convenient, moving to <section type=article> fails. |
| 12:34 | <Lachy> | adactio, there is no generalised rule |
| 12:34 | <Lachy> | it has to be judged on a case by case basis |
| 12:34 | <adactio> | Lachy: that's a fair point BUT the problem I'm seeing is confusion amongst authors about when to use <article> and when to use <section> because the two are currently uncoupled in the spec, despite the fact that they are very, very similar. |
| 12:35 | <Hixie> | from what i've seen, authors do not have such confusion |
| 12:35 | <Hixie> | they use them correctly |
| 12:35 | <Lachy> | yes, they are intentionally similar, because <article> is indeed a specialised type of <section> |
| 12:35 | <Hixie> | as are <nav> and <aside> |
| 12:35 | <Lachy> | yes |
| 12:36 | <adactio> | I admit there is a precedent here: <ol> and <ul> rather then <list ordered> and <list> but at least it's easy for authors to grok "they're both kinds of lists." But with <section> and <article>, they're both kinds of ... stuff. |
| 12:36 | <Hixie> | the spec actually mentions <article> in the <section> section now, by the way |
| 12:36 | <Hixie> | as of about 30 minute sago |
| 12:36 | <da3d> | I don't really see where the confusion comes from, I just think of them as: article = large gob of stand-alone content, section = part of larger thingy |
| 12:36 | <Hixie> | so they're no longer uncoupled |
| 12:36 | <adactio> | Hixie: Good. Thank you for that. |
| 12:37 | <Lachy> | Hixie, do you mean this note? "Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element." |
| 12:37 | <adactio> | da3d: why do you think an article must be a "large" gob? |
| 12:38 | <Hixie> | Lachy: yeah |
| 12:38 | <remysharp> | da3d: equally, a section can be both part of a larger thingy, or just a small part of an article, or contain articles, or not. |
| 12:38 | <adactio> | da3d: here are two pages of articles. The gobs are not large: http://www.last.fm/user/adactio/shoutbox http://twitter.com/adactio |
| 12:39 | <Lachy> | da3d, basing it on size doesn't seem sensible, since both articles and other general sections can be of any size |
| 12:39 | <Lachy> | you have to base the distinction on concepts, rather than any physical attribute of the content |
| 12:39 | <da3d> | adactio: "large" in relation to smaller sections, anyway... |
| 12:40 | <da3d> | But the size is irrelevant, so feel free to ignore the large word :p |
| 12:41 | <adactio> | da3d: articles can be bigger than sections. sections can be bigger than articles. |
| 12:41 | <Lachy> | indeed. Sections can even contain many articles, and do in some cases |
| 12:42 | <da3d> | true, but I'm mostly thinking of how I would use them (if I had a website) and I don't use twitter and such... |
| 12:42 | <adactio> | So ...although <section> and <article> are using different element names, is it fair to say that an <article> is a specialised type of <section>? |
| 12:43 | <adactio> | Similar to <ul> or <ol> ...or more appropriately <input> and <textarea> (which could have been <input type="textarea">) |
| 12:43 | <Lachy> | consider the case the Top Stories section of a news site, where you would have a <section><h1>Top Stories</h1> ... </section> which then contains 3 or 4, or whatever, <article> elements, one for each of the top storeis |
| 12:44 | <adactio> | Lachy: yup, and each of those <article> elements could have been a <section> element, except the author decides "*these* pieces of content could be distributed or reused". |
| 12:44 | <Lachy> | adactio, no, <input type=textarea> wouldn't work too well since you'd have to cram all that content into a value attribute, including line breaks and stuff |
| 12:45 | <adactio> | Lachy: okay, bad example, but you get my point. |
| 12:45 | <Lachy> | yeah, I sort of get your point |
| 12:46 | <adactio> | All <article>s are sections. Not all sections are <article>s. (just as all acronyms are abbreviations but not all abbreviations are acronyms) |
| 12:47 | <Lachy> | I have a problem with distributable and reusable being considered as criteria for the <article> element. The criteria should just be independence |
| 12:48 | <Lachy> | though, even that's doesn't convey it entirely accurately |
| 12:48 | <Lachy> | adactio, yes, that correct |
| 12:48 | <adactio> | Lachy: So, in your example "the Top Stories section of a news site", each of those <article> elements could have been a <section> element, except the author decides "*these* pieces of content **are independent**" |
| 12:49 | <Lachy> | yes |
| 12:49 | <remysharp> | but section has the same property doesn't it |
| 12:49 | <remysharp> | sections are supposed to be independent chunks of content |
| 12:49 | <remysharp> | ? |
| 12:49 | <adactio> | The <article> element looks like a duck, walks like a duck and quacks like a duck (where the duck is the <section> element). |
| 12:50 | <Binarytales> | but it's a duck that has figured out it can fly south on its own |
| 12:50 | <adactio> | remysharp: ah no, you see sections are chunks of content, articles are *independent* chunks of content. That one word makes all the difference. |
| 12:50 | <Lachy> | remysharp, not entirely. A chapter in a book is not independent from the whole. It's just a subsection |
| 12:51 | <remysharp> | ok. I can see that. |
| 12:52 | <takkaria> | some chapters are independent |
| 12:52 | <remysharp> | any chance of plain ol' english being put in the spec then - Lachy's example is pretty easy to see applied to a web page/site |
| 12:52 | <Hixie> | Lachy: the "reusable" part is key, i think, more than the "independent" part, because the important sense of "independent" that leads to <article> use is that the thing is really independent enough to be reused (e.g. put on a page of its own) |
| 12:52 | <adactio> | I can see the problem that is being solved here. An article is a specialised type of content. There are two ways to solve this problem: a new element (<article>) or an attribute on the existing element (<section @article>). |
| 12:52 | <Hixie> | remysharp: is what the spec says now not ok? (it's changed a lot tonight) |
| 12:53 | gsnedders | blinks at http://www.pitpass.com/fes_php/pitpass_news_item.php?fes_art_id=39026 |
| 12:53 | <remysharp> | Hixie: they just need really simple examples (section & article) that define which should be used when |
| 12:53 | <remysharp> | Hixie: let me double check what they show now |
| 12:53 | <adactio> | I can see why a new element is more convenient for typing, but I thought there would be more resistance to creating a new element when the problem can be otherwise solved (see, for example, the understandable resistance to creating a new element for captioning <details> and <figure>). |
| 12:54 | <Hixie> | the thing with the new element for <details> and <figure> is that there's already 18 elements that mean "heading" or some variant thereof |
| 12:54 | <Hixie> | 18! |
| 12:55 | <Hixie> | i mean that's like more than half the language |
| 12:55 | <Hixie> | there comes a point where one has to say enough! let's reuse the existing elements! |
| 12:55 | <Hixie> | but with <article>, <section>, <nav> and <aside>, that's only 4 elements |
| 12:55 | <Hixie> | 5 if you count <body> |
| 12:55 | <Hixie> | so there's a lot less resistence |
| 12:56 | <adactio> | Hixie: That makes sense. But I am seeing a lot of confusion from authors and I think there would be less confusion if articles were explicitly a specialised type of section. |
| 12:57 | <Hixie> | where is the confusion you're seeing? |
| 12:57 | <Hixie> | it seems authors are using these two elements correctly |
| 12:57 | <Hixie> | the confusion you mentioned on your blog post was about the spec's definitions, which is now fixed |
| 12:58 | <adactio> | Hixie: authors unsure about 1) when to use article and when to use section (although admittedly a lot of that is about about authors looking for an element to mark up "main content") and 2) can sections be nested in articles and visa-versa. |
| 12:58 | <Hixie> | pointers? |
| 12:59 | <Hixie> | i'd love to study this in more detail |
| 12:59 | <Hixie> | i haven't seen much of that, most of what i've seen has authors using the elements correctly apparently with little comment |
| 12:59 | <adactio> | Hixie: I wish I had some concrete material I could point you to. :-( I'll see if I can find some relevant discussions and blog posts. |
| 12:59 | <Hixie> | cool, thanks |
| 13:00 | <adactio> | Hixie: don't get me wrong: there are some very good examples out there. Ted's tutorial is the best I've seen so far. |
| 13:01 | <annevk42> | we should do a markup study of html5gallary |
| 13:01 | <annevk42> | gallery even |
| 13:01 | <adactio> | annevk42: that's a good idea. |
| 13:01 | <Lachy> | I think the problem is that there are grey areas where either article or section could be used, and trying to draw a fine line in that grey area is difficult |
| 13:01 | <adactio> | Lachy: no argument there. :-) |
| 13:01 | <annevk42> | maybe we can do it in some distributed way so that everyone checks ten pages or so and reports on a wiki? |
| 13:01 | <Hixie> | annevk42: yeah |
| 13:02 | <Hixie> | annevk42: that'd be awesome |
| 13:03 | <remysharp> | Hixie: regarding examples, it would be useful to see an example of how section works when it's not in the context of an article |
| 13:04 | <remysharp> | in the example text (chapters, tabs, etc) all of those would sit inside a wrapping article element |
| 13:04 | <Lachy> | adactio, where is Ted's tutorial that you mentioned? |
| 13:04 | <adactio> | Lachy: lemme find it... |
| 13:04 | <Hixie> | remysharp: almost all the examples of <section> in the spec that aren't in the <section> section are examples of that :-) |
| 13:05 | <Hixie> | remysharp: you're right it'd be nice to have some in the <section> section |
| 13:05 | <Hixie> | remysharp: can you file a bug with the little widget at the bottom of the spec window? |
| 13:05 | <Hixie> | basically just saying what you said above |
| 13:05 | <remysharp> | ok, sure. |
| 13:05 | <adactio> | Lachy: http://edward.oconnor.cx/2009/09/using-the-html5-sectioning-elements (though again, the context is marking up a blog). |
| 13:05 | <Hixie> | thanks |
| 13:06 | <adactio> | Hixie: do you think it would be useful if the spec *explicitly* said "an article is a specialised type of section"? |
| 13:06 | <remysharp> | Hixie: I'm using the "submit review comment" - right? |
| 13:06 | <Hixie> | remysharp: yep |
| 13:07 | <Lachy> | adactio, that's by Edward, not someone named Ted, whoever that is. Did you just get his name mixed up? |
| 13:07 | <adactio> | Lachy: He goes by Ted IRL. |
| 13:07 | <Hixie> | adactio: i think it might lead to the confusion that your study showed -- i think the main reason article and section were confused in your study is that the description of <article> said "section" |
| 13:07 | <Lachy> | he goes by hober in here |
| 13:07 | <adactio> | Lachy: this isn't RL. ;-) |
| 13:08 | <Lachy> | I don't know him in real life. He only exists in IRC :-) |
| 13:09 | <adactio> | Hixie: then maybe the old description was explicit enough. It may be necessary to say "the <article> element can be thought of as a specialised type of <section> element." |
| 13:09 | <adactio> | Lachy: I can testify that he exists beyond the confines of IRC (and is a great guy, too). :-) |
| 13:10 | <Hixie> | adactio: http://www.whatwg.org/specs/web-apps/current-work/#sectioning-content-0 |
| 13:10 | <annevk42> | adactio, isn't that Edward and not Ted? |
| 13:10 | <Hixie> | adactio: each of those elements is marked as being "Category: Sectioning content" |
| 13:10 | <adactio> | annevk42: Oh do keep up. Lachy, you tell him. ;-) |
| 13:11 | <Hixie> | adactio: isn't that explicit enough? |
| 13:11 | <Lachy> | annevk42, apparently, he goes by Ted in real life. |
| 13:11 | <annevk42> | adactio, sorry |
| 13:11 | <adactio> | Hixie: alas, I don't think it is. |
| 13:11 | <annevk42> | adactio, I thought hober was his nickname |
| 13:11 | <annevk42> | very confusing all |
| 13:11 | <Hixie> | adactio: i fear making the spec repeat itself will just make it so verbose that people will read it even less than now |
| 13:12 | <Hixie> | adactio: i agree that prose to that effect would make sense in informative author-specific drafts like lachy's and mike's though |
| 13:12 | <adactio> | Hixie: that's a fair point. |
| 13:12 | <Lachy> | adactio, file a bug on my authoring guide and I'll make sure it says something suitable |
| 13:12 | <adactio> | It would certainly be A Good Thing if tutorials explicitly said "think of <article> as being like a specialised <section>" |
| 13:13 | <Lachy> | http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG&component=Lachlan%20Hunt%27s%20%22HTML%205%20Reference%22 |
| 13:14 | <Lachy> | adactio, I'll also try and explain it better in the article I'm working on here http://lachy.id.au/temp/article/ |
| 13:15 | <adactio> | Lachy: Excellent. I'll do the same in any blogging I do on these elements. |
| 13:15 | <adactio> | Though I'm still not convinced that there needs to be two different elements for such similar use cases. |
| 13:16 | <Lachy> | hsivonen, are you still planning to file bugs about those issues with the HTML5 Reference you mentioned in IRC the other day? |
| 13:17 | <Lachy> | I remember one was about mentioning the ability to use xmlns prefixes. I can't remember what the other one was |
| 13:17 | <Hixie> | adactio: how would you get rid of the need for using classes to style <div class="post">, if not with a new element? |
| 13:17 | <Lachy> | Hixie, it depends if you see that as a real problem that needs to be solved |
| 13:18 | <Hixie> | it's the problem that pretty much all the sectioning elements are trying to solve |
| 13:25 | <GPHemsley> | No approval for my list message? :( |
| 13:25 | <gsnedders> | GPHemsley: Nobody ever looks at the moderation queue, esp. not the one person who has access :P |
| 13:25 | <GPHemsley> | meh |
| 13:26 | <Lachy> | GPHemsley, which list? |
| 13:26 | <GPHemsley> | whatwg |
| 13:26 | <Hixie> | that list gets about 1000 spam messages a day |
| 13:26 | <Hixie> | no way i'm checking that queue :-P |
| 13:26 | <Lachy> | GPHemsley, are you subscribed? It should go through automatically |
| 13:27 | <GPHemsley> | Lachy: Yeah, I am. |
| 13:27 | <annevk42> | if you get an approval message you used the wrong email address |
| 13:28 | <GPHemsley> | hmm, you know what... I think I'm subscribed using a + e-mail address |
| 13:28 | <GPHemsley> | not sure how to make Gmail send from one |
| 13:29 | <wm3|lunch> | GPHemsley: you should get a drop-down list for 'from' in gmail web client for extra email addresses in your gmail account |
| 13:29 | <GPHemsley> | wm3|lunch: That's only for the ones you specifically attach |
| 13:29 | <adactio> | Hixie: the CSS attribute selector enables authors to target <section @article> specifically: section[article] { } |
| 13:29 | <GPHemsley> | wm3|lunch: You can arbitrarily give out + e-mail addresses without having to do anything to create them |
| 13:30 | <wm3|lunch> | ah, not used that feature :) |
| 13:31 | <Binarytales> | I use it for all my mailing list subs. Makes it super easy to filter them |
| 13:31 | <GPHemsley> | Hixie: I did accidentally send the message to you personally first. |
| 13:31 | <GPHemsley> | Binarytales: Yeah, that was the idea. |
| 13:33 | <Lachy> | Binarytales, filtering on List-id is just as easy, usually |
| 13:34 | <Lachy> | though, the +foo email addresses sort of have their use as a spam filtering mechanism, as I've heard others claim, I don't think they would be entirely effective |
| 13:36 | <Hixie> | adactio: that's no better than section.article or div.article |
| 13:36 | <Hixie> | adactio: the whole point is to avoid having to use attribute selectors but to just have a tag name |
| 13:36 | <Hixie> | ok, bed time |
| 13:37 | <Hixie> | nn |
| 13:37 | <Lachy> | code readbility is another issue it addresses, since you can easily match a </article> with its start tag, whereas that would be harder if you had used <section> (or even <div>) for everything |
| 13:48 | <adactio> | Hixie: why the preference for element selectors over other kinds of selectors? |
| 13:48 | <adactio> | Hixie: it seems arbitrary to me, |
| 13:52 | <annevk42> | they're better understood |
| 13:52 | <annevk42> | and they're fast |
| 13:52 | <annevk42> | i made a small start with the markup survey: http://wiki.whatwg.org/wiki/HTML5_Survey |
| 13:53 | <annevk42> | at this point it would probably be good to comment on the setup |
| 13:53 | <annevk42> | i'm not too happy about it, but everything else seems a lot more complicated |
| 13:54 | <adactio> | annevk42: but if I want to style the publication date of an article, doesn't it make sense to use time[pubdate]? |
| 13:57 | <annevk42> | sure |
| 13:58 | <adactio> | annevk: the same applies for section[article]. And in the use case that gets mentioned 99% of the time when talking about articles (i.e. a blog), it is likely that the only sections will be articles so authors will be able to use the element selector. |
| 13:59 | <annevk42> | why wouldn't a blog use nested sections? |
| 13:59 | <annevk42> | lots of blog articles have headings |
| 14:00 | <adactio> | If there is pushback against using attributes because you think they are harder to style, how are authors going to distinguish blog post <article>s and blog comment <article>s? They could use classes but we've heard how bad that is. Shouldn't we have a <comment> element then? |
| 14:00 | <annevk42> | news articles too |
| 14:00 | <GPHemsley> | I still like <item> |
| 14:00 | <annevk42> | article > article? |
| 14:00 | <adactio> | annevk42: section[article] section { } allows me to target sections within articles. |
| 14:00 | <GPHemsley> | but I can't stick around to participate in the discussion |
| 14:03 | <Philip`> | GPHemsley: You can add the + addresses in Gmail's settings page, and then send mail from them |
| 14:05 | Philip` | has given up using + addresses in Gmail because it makes it trivial to filter mailing lists without relying on recipient address, and it filters spam pretty well so there's not much value in segregating the addresses you give to different sites |
| 14:05 | <annevk42> | adactio, sure, and section[nav] alloes you to target what could also be <nav> |
| 14:05 | <Philip`> | "we're not maximising the area of confusion, the spec is incredibly detailed and has more examples and notes and explanatory text than a school textbook" |
| 14:05 | <Philip`> | I don't think incredible detail and many examples necessarily make things less confusing |
| 14:06 | <Philip`> | It's like authors are trying to fit a polynomial to the data points provided by the spec, and the more data points there are, the more complex the understanding they derive from it |
| 14:06 | <Philip`> | "I think the spec says I should use <article> for this and this and this and this, but certainly not for this and this and this. Should I use it for this other thing?" |
| 14:06 | <annevk42> | adactio, afaict <article> is different and common enough for its own element, and blog comments are not different in semantics to warrant something new |
| 14:06 | <adactio> | annevk42: True, but authors aren't confused about when to use <nav>. And <nav> doesn't share 99.99% of its DNA with <section>. |
| 14:07 | <jgraham_> | adactio: You keep saying that but I still don't think it\s true |
| 14:07 | <annevk42> | adactio, the former is not entirely clear (a more thorough markup study might reveal that) and the latter somewhat subjective |
| 14:07 | <adactio> | annevk42: I agree with you that blog comments are not different enough to warrant their own element. I disagree that blog posts are different enough to warrant their own element (which is effectively what <article> is). |
| 14:07 | jgraham_ | thought we dispelled that notion some hours ago |
| 14:08 | <annevk42> | adactio, i'm not too convinced about <article> either, but making it an attribute is worse |
| 14:08 | hsivonen | notices that the URL space of the management UI of his router spells "gauge" wrong |
| 14:08 | <adactio> | My example of blog comments was to show that the solution of having two different elements (<section> and <article>) as opposed to one element (<section> and <section @article>) does not actually make it any easier for authors to target with CSS. |
| 14:08 | <hsivonen> | also, it calls a progress bar a gauge |
| 14:08 | <hsivonen> | or, well, "guage" |
| 14:09 | <Dashiva> | <bar> |
| 14:09 | <annevk42> | adactio, ok, it does make your markup clearer |
| 14:09 | <adactio> | annevk42: that's a matter of opinion. I don't think there's a big difference between <section article> and <article>. |
| 14:10 | <adactio> | annevk42: and frankly, that's a pretty flimsy reason for creating a new element. |
| 14:10 | <beowulf> | http://www.guardian.co.uk/sport/2009/sep/15/flavio-briatore-renault-singapore-nelson-piquet-transcript # The Grauniad like the dialog guidelines... |
| 14:10 | Philip` | proposes updating English to rename gauge to gayj |
| 14:11 | <hsivonen> | apparently en-GB-x-hixie isn't quite enough to be English5 |
| 14:12 | <annevk42> | adactio, that's pretty much the reason we have <nav> and all |
| 14:12 | <Lachy> | Philip`, the way to update the english langauge is to have the word published enough so that it meets the criteria that the OED uses for deciding when to add a new word |
| 14:12 | <annevk42> | adactio, so you don't have to wade through a bunch of <div>s |
| 14:12 | <annevk42> | adactio, there's other benefits too of course |
| 14:12 | <Binarytales> | i thought the main reason we have <nav> is for accessibility |
| 14:13 | <adactio> | annevk42: But <nav> has a *distinct* use case. So does <header>. So does <footer> (although there's some overlap with <aside>). Whereas <section> and <article> are so similar as to be redundant. |
| 14:13 | <hsivonen> | Lachy: oops. Sorry. I forgot to file the bugs when I got to a decent text input method |
| 14:13 | <annevk42> | adactio, it seems people disagree on that |
| 14:13 | <Philip`> | Lachy: I hope "langauge" was a joke :-p |
| 14:14 | <annevk42> | adactio, I don't feel strongly, apart from not wanting to turn it into an attribute |
| 14:14 | <Philip`> | Lachy: Let's put <gayj> in HTML5, and then it will be used widely enough to become an official word |
| 14:14 | <Lachy> | Philip`, let's just pretend it was :-) |
| 14:14 | <adactio> | annevk42: Fair enough. I don't feel strongly about introducing an attribute but I do feel strongly that the existence of two very, very similar elements is a problem. |
| 14:15 | <annevk42> | adactio, then you should continue the little survey i started and figure out of its an actual problem for authors |
| 14:15 | <annevk42> | adactio, or argue for removal |
| 14:15 | <annevk42> | or both |
| 14:16 | <adactio> | A more complex parsing rule than simply using an attribute would be something like "the parent <section> of a <time> element with a @pubdate attribute is a special kind of section called an article, which could be distributed or reused" |
| 14:16 | <annevk42> | that wouldn't work for widgets |
| 14:16 | <adactio> | annevk42: The thing about the survey is, it would have to contain more than just blog content. The use case is clear for blogs and very unclear for everything else. |
| 14:17 | <adactio> | annevk42: Frankly, most authors won't think of using <article> for widgets as it is (see Remy's comments above). |
| 14:17 | <annevk42> | html5gallery includes both blogs and non-blogs |
| 14:17 | <hsivonen> | Lachy: bugs filed |
| 14:17 | <Lachy> | thanks |
| 14:19 | Lachy | should start addressing these bugs soon http://www.w3.org/Bugs/Public/buglist.cgi?product=HTML%20WG&component=Lachlan%20Hunt%27s%20%22HTML%205%20Reference%22 |
| 14:23 | <hsivonen> | interesting post way back from 2003: http://www.goer.org/Journal/2003/08/orthodoxies.html |
| 14:23 | <hsivonen> | (via mattur) |
| 14:25 | <Binarytales> | Okay, going through the html5gallery I found this site: http://resume.chuckharmston.com/ |
| 14:26 | <Binarytales> | he uses sections where he could argubaly be using articles |
| 14:27 | <hsivonen> | http://www.jboss.org/reststar/ |
| 14:29 | <Philip`> | "an element that executes arbitrary author-provided inline assembler" |
| 14:29 | <Philip`> | That sounds like Google's NaCl |
| 14:29 | <annevk42> | Binarytales, you want to find pages where it's the other way around |
| 14:30 | <Lachy> | Binarytales, I would probably opt to use section for that case too, though I can see how article would be somewhat acceptable too |
| 14:30 | <Binarytales> | well if he did use articles then I could easily have said. "he uses articles where he could arguably be using sections" |
| 14:30 | <Binarytales> | thus, the elements are interchangeable, which is the point adactio is making |
| 14:31 | <Lachy> | Binarytales, that looks like one of those grey areas, though I personally think section is more correct because each is just a subsection of the whole resume |
| 14:32 | <annevk42> | hsivonen, so I looked up middleware and it didn't get much clearer |
| 14:33 | <annevk42> | hsivonen, I think I do get the WS-* vs REST debate |
| 14:33 | <adactio> | This is my point. When people here disagree about when to use <section> and when to use <article>, how are other authors supposed to figure it out? You just don't see this same level of confusion around <nav>, <header> or <footer>. |
| 14:33 | <adactio> | I can see how, in principle, <article> is no different to those elements but in practice, it's *way* more confusing. |
| 14:33 | <Binarytales> | yes but surely his section id="biography" is independent and re-suable, if he was speking at conference yoy could use that on the speakers page |
| 14:33 | <Binarytales> | and thus its an article |
| 14:34 | <karlcow> | hsivonen: the comments on goerg article are interesting too. |
| 14:34 | <hsivonen> | annevk42: I hope it's satire as stated in https://twitter.com/psd/status/4027785827 |
| 14:34 | <adactio> | Binarytales: that sounds like it satisfies the "independent" and "reusable" criteria to me. |
| 14:35 | <karlcow> | hsivonen: difficult to know if it's really satire or if psd is being saccarstic |
| 14:35 | <Binarytales> | adactio: yeah exactly |
| 14:35 | <adactio> | It will be interesting see if *anybody* is using <article> to mark up widgets. |
| 14:36 | <Philip`> | I guess the problem with REST is there isn't a lot of pointless complexity that vendors can sell you, so it needs to be rearchitected to have more layers of abstraction that they can sell |
| 14:37 | <hsivonen> | karlcow: indeed. it's a bit of a problem that it's so hard to tell |
| 14:37 | <karlcow> | REST-* should become RIP |
| 14:39 | <Lachy> | what is "REST-*"? |
| 14:40 | <karlcow> | Lachy: a deathstar :) |
| 14:41 | <hsivonen> | Lachy: http://rest-star.org/ |
| 14:44 | <annevk42> | hsivonen, looks like it |
| 14:44 | <hsivonen> | annevk42: looks like what? |
| 14:44 | <boblet> | aaw, I missed the section/article conversation |
| 14:44 | <annevk42> | an elaborate joke |
| 14:45 | <hsivonen> | annevk42: it's a bit disturbing if it isn't |
| 14:45 | <Philip`> | Seems too elaborate and too dull to actually be a joke |
| 14:46 | <Philip`> | It points to stuff like http://groups.google.com/group/reststar-board/browse_thread/thread/96ad3d4d28ec69ae |
| 14:47 | <Philip`> | which sounds genuine |
| 14:47 | <karlcow> | the only thing which makes it a joke is the lack of activity on the mailing list |
| 14:48 | <Lachy> | in http://www.jboss.org/reststar/overview/why.html it compares it with WS-*. But it's not clear to me what "WS-*" referrs to. |
| 14:48 | <karlcow> | Though if it's a joke, it's making fun of whatwg, w3c, and openwebfoundation at the same time. Which is quite genius indeed |
| 14:49 | <karlcow> | Lachy: have you lived in a case these last years? |
| 14:49 | <karlcow> | s/case/cave/ |
| 14:49 | <Lachy> | I've just never seen that abbreviation before |
| 14:49 | <karlcow> | Lachy: see for example http://bitworking.org/news/125/REST-and-WS |
| 14:50 | <karlcow> | WS-* stands for the full stack of Web Services which was pushed at W3C by some vendors to sell the next generation of web fashioned Corba |
| 14:51 | <karlcow> | It created a lot of discussions, pains, and schism |
| 14:51 | <Lachy> | karlcow, ok. I ignored pretty much all of that stuff from the W3C |
| 14:52 | <Lachy> | so it includes stuff like SOAP and WSDL? |
| 14:53 | <karlcow> | Lachy: yes |
| 14:53 | <Lachy> | if so, then that would explain why I don't know much about it, since that stuff was completely irrelevant to me |
| 14:54 | <Philip`> | I remember looking at Microsoft's MSDN front page many years ago, and it was all talking about SOAP |
| 14:54 | <Philip`> | and I read various things it linked to |
| 14:54 | <Philip`> | but I had absolutely no idea what SOAP was and couldn't work it out |
| 14:55 | <workmad3> | isn't soap that stuff you use in a bath? |
| 14:55 | <Philip`> | It seems they tend to skip the part where they actually explain what's basically going on |
| 14:55 | <Philip`> | workmad3: No, that's pumice |
| 14:55 | <Lachy> | workmad3, some people do. Others use it for sending messages to each other |
| 14:55 | <karlcow> | Philip`: XML-RPC -> SOAP 1 -> SOAP 1.2 |
| 14:56 | <karlcow> | http://www.xmlrpc.com/ |
| 14:56 | <karlcow> | by Dave Winer |
| 14:56 | <karlcow> | then pushed by Dave Winer and MS at W3C |
| 14:58 | <karlcow> | http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ |
| 14:58 | <karlcow> | For Microsoft at the origin it was Don Box |
| 14:59 | <karlcow> | and a few others |
| 15:18 | <zcorpan> | so when will firefox remove the border around <a href><img> and <img usemap>? |
| 15:18 | <annevk42> | is there a bug? |
| 15:19 | <annevk42> | prolly easy enough to patch if they implement it with CSS rules |
| 15:21 | <Lachy> | they do. It's in html.css |
| 15:21 | <Lachy> | *|*:-moz-any-link img, img[usemap], object[usemap] { |
| 15:21 | <Lachy> | border: 2px solid; |
| 15:21 | <Lachy> | } |
| 15:21 | <Lachy> | img[usemap], object[usemap] { |
| 15:21 | <Lachy> | color: blue; |
| 15:21 | <Lachy> | } |
| 15:23 | <Lachy> | does IE still add the border around images? |
| 15:24 | <Lachy> | yep, it does |
| 15:36 | <Philip`> | When will Opera add a border around <a href><img>, so I don't write pages that I think are fine and then find out days later they look hideous in Firefox? |
| 15:37 | <karlcow> | Philip`: you can reset your css |
| 15:40 | <karlcow> | I systematically do @import url("/reset.css"); with http://meyerweb.com/eric/tools/css/reset/ |
| 15:40 | <karlcow> | and add my own style after. You can even create your own generic one. |
| 15:41 | <annevk42> | it adds so much bloat |
| 15:41 | <Philip`> | I'd prefer not to systematically start all my pages by fighting against the browser |
| 15:44 | <karlcow> | Philip`: I'll try to repeat that to the Agency Web developers where I'm working ;) |
| 15:47 | <Philip`> | I don't expect their preferences will be the same as mine |
| 15:48 | <karlcow> | Philip`: understood, it is more the "not… fighting against the browser" which made me smile :) |
| 15:53 | boblet | wishes there was a wiki with a list of the differences that reset.css addresses |
| 15:53 | <Philip`> | They wouldn't prefer not to fight against the browser? |
| 15:58 | <karlcow> | Philip`: definitely |
| 15:59 | <karlcow> | given that the support of ie6 is often a requirement imposed by the client (specifically in big companies). |
| 16:02 | <Philip`> | Hmm, they definitely wouldn't not prefer it? |
| 16:03 | Philip` | would have thought it would be considered a necessary evil, not an actual desire |
| 16:03 | <annevk2> | yeah man, that's the whole fun part of doing HTML and CSS |
| 16:03 | <annevk2> | browser bugs |
| 16:03 | <annevk2> | though admittedly I since moved on to fix some of them and introduce a bunch more |
| 16:04 | <boblet> | heh |
| 16:07 | <Lachy> | Philip`, add a user stylesheet to Opera that applies the ugly borders to images by default |
| 16:08 | <Lachy> | Philip`, this should work: |
| 16:08 | <Lachy> | :visited img, :link img, img[usemap], object[usemap] { border: 2px solid; } |
| 16:08 | <Lachy> | img[usemap], object[usemap] { color: blue; } |
| 16:08 | <Rik|work> | karlcow: don't use @import http://stevesouders.com/blog/2009/04/09/dont-use-import/ |
| 16:13 | <Philip`> | Why go to so much effort trying to find an efficient way to serve multiple CSS files, rather than simply concatenating them all into one? |
| 16:13 | <karlcow> | Rik|work: reading it |
| 16:14 | <boblet> | Philip`: because of that A List Apart article |
| 16:14 | <Philip`> | boblet: Which one? |
| 16:14 | <Rik|work> | Philip`: because you maybe don't want to concatenate them all |
| 16:15 | <boblet> | Philip`: http://www.alistapart.com/articles/progressiveenhancementwithcss/ |
| 16:15 | <Rik|work> | Philip`: I don't want to loadd CSS styles for a private section on a public section, i don't want to load all my styles on the home page, etc etc |
| 16:16 | <boblet> | it’s based on the idea that you don’t want styles for every page loaded on each page because they may be quite divergent |
| 16:16 | <boblet> | unfortunately performance hit of a loading stylesheet is probably bigger than any savings from eg not loading forms.css |
| 16:18 | <Philip`> | Yeah, seems like saving round trips is much more important than saving bytes |
| 16:18 | <boblet> | admittedly I’ve never done a huge octopus-like site that would warrant it, but for me definitely more pain than gain |
| 16:18 | <karlcow> | Philip`: there are many reasons, some given by Rik|work. There is also maintenance in a multi-designer team. |
| 16:19 | <boblet> | I think a base problem is long stylesheets are hard to create because most editing tools don’t help (notable exception CSSEdit) |
| 16:19 | <karlcow> | We could have a level of indirection in deployment scripts but prone to errors. aka put all styles in one style before deploying |
| 16:19 | <Philip`> | karlcow: Maintenance doesn't seem too relevant, because you could use <link rel=stylesheet href=concatenate.php?type,layout,color> (with suitable caching in front of the script) and it would have no effect on maintenance |
| 16:20 | <Philip`> | s/no/little/ |
| 16:21 | <Philip`> | and if you're someone who cares about site performance then you'll be able to cope with a little scripting and caching |
| 16:21 | <boblet> | karlcow: I think git etc + oocss ideas solve maintenance issue |
| 16:21 | <boblet> | (multiple files = multiple smaller maintenance problems) |
| 16:22 | <Rik|work> | anyway, avoiding @import in favor of <link> is not a big task and provides a good improvement on performances |
| 16:22 | <workmad3> | sass also helps with that |
| 16:23 | karlcow | is trying to imagine it in dev environments. With devs/html integrator working on local using svn, then dev.example.org, qa.example.org, preprod.example.org, staging.example.org, example.org (prod) |
| 16:23 | <boblet> | workmad3: now you have an additional maintenance problem ;-) |
| 16:23 | <workmad3> | (although that seems more on the RoR side of web frameworks so far)... it lets you have @import statements that the sass compiler will pull together beforehand |
| 16:23 | <workmad3> | no more than adding any other tool to help you manage css :P |
| 16:23 | <boblet> | karlcow: you wouldn’t want to do that using svn—you need distributed |
| 16:24 | <karlcow> | boblet: except there is theory and actual structure in place ;) |
| 16:24 | <boblet> | workmad3: indeed. Everyone should just go naked! |
| 16:24 | <boblet> | karlcow: ah. that :) yep, that can be a problem |
| 16:25 | <workmad3> | boblet: that seems to be your argument :P I suggest adding a tool that helps the problem, you say it increases maintenance... therefore go naked and avoid having to repair your clothes :P |
| 16:26 | <boblet> | workmad3: you’re a genius! problem solved :D |
| 16:26 | <boblet> | j/k |
| 16:26 | <boblet> | sass does indeed look very nice |
| 16:27 | <workmad3> | and yeah, I agree that sass isn't a solution for everyone... but it is useful and helpful :) |
| 16:28 | <workmad3> | and it being able to compile multiple sass stylesheets into a single css stylesheet does exactly what you seemed to want... ease your stylesheet maintenance without having loads of <link> or @import statements :) |
| 16:33 | <GPHemsley> | alright, so, that worked... but the threader marked it as a new thread... :/ |
| 16:33 | GPHemsley | stabs Gmail for causing so much trouble |
| 16:36 | <workmad3> | heh :) |
| 16:45 | <karlcow> | http://www.todayandtomorrow.net/2009/09/16/scrollbars/ |
| 16:45 | karlcow | remembers all strange experiments that people did with frames and tables when they have been implemented. |
| 16:46 | <Rik|work> | why is that chrome and safari only ? |
| 16:47 | <karlcow> | no idea. |
| 16:47 | <karlcow> | The Website of the author is… creative :) http://www.the389.com/ |
| 16:48 | gsnedders | wonders how accessible that is ;P |
| 16:56 | <TabAtkins> | Hrm, the the389.com dude has some pretty crazy-looking stuff. |
| 17:45 | <annevk2> | hmm, detection of character encodings in XML is non-normative and incomplete: http://www.w3.org/TR/xml/#sec-guessing |
| 17:45 | <annevk2> | good times |
| 17:54 | <zcorpan> | annevk2: send email to public-xml-core-wg |
| 18:00 | <annevk2> | zcorpan, what chance do you give for errata? |
| 18:03 | <zcorpan> | i think it's unlikely that the wg will fix the rules and make them normative |
| 18:04 | <zcorpan> | but who knows |
| 18:04 | <zcorpan> | i intend to suggest adding the set of entities in xml at some point |
| 18:06 | <annevk2> | between that and my issue i've a 90% chance :p |
| 18:30 | <annevk2> | http://twitter.com/ppk/status/4031314392 -- "I'm on the verge of deciding that the HTML5 drag and drop is just a fucking disaster and we should continue using old-school scripts." |
| 18:50 | <Philip`> | annevk2: Blog typo: "Japenese" |
| 19:04 | <annevk42> | ta, fixed |
| 19:05 | <annevk42> | also changed labeled to US spelling and fixed authoritative |
| 19:08 | <Philip`> | "If only UTF-8 was the accepted encoding well before the Web took off we would not be in this mess" - wasn't UTF-8 the accepted encoding well before XML took off, and it decided to stick with the encoding mess anyway? |
| 19:14 | <hsivonen> | Philip`: UTF-8 existed but wasn't yet accepted by everyone in 1998 |
| 19:14 | <hsivonen> | Philip`: XML and HTML 4.01 probably helped sell Unicode |
| 19:17 | <Philip`> | Ah, right |
| 19:17 | Philip` | isn't very good at history |
| 19:19 | <hsivonen> | annevk42: https://bugzilla.mozilla.org/show_bug.cgi?id=452915 |
| 19:22 | <Lachy> | --> "IE7 seems to do the same as Mozilla, afaict, so it seems to me that Mozilla is doing it correctly." |
| 19:23 | <Lachy> | this is one case where we shouldn't rely on IE7. Those borders are hated by most designers and always remove them |
| 19:27 | <annevk42> | replied |
| 19:31 | GPHemsley | replied, too |
| 19:44 | <GPHemsley> | heh, I like this quote: "IE = WYSIWTF" |
| 20:01 | TabAtkins | is on day five of no internet at home. He's finally broken down and taken his laptop to Starbucks so he can get some actual work done. |
| 20:21 | <Philip`> | TabAtkins: Do you have no alternative ways to get internet at home? |
| 20:22 | Philip` | uses a mobile broadband thing which isn't too expensive (if you don't use it much) and is really very useful when the internet goes down for days |
| 20:22 | <TabAtkins> | Philip`: No, other than Opera Mini on my phone. |
| 20:23 | <Philip`> | Can't you buy something that will work? |
| 20:23 | <TabAtkins> | Dunno. Possibly. In the meantime I'll just be taking my desktop to my friend's house tomorrow, and working from there until the net gets fixed. |
| 20:25 | <Philip`> | Seems much more effort than spending five minutes and the equivalent of £40 in a shop to get a USB device that plugs in to a computer and gives you your internets back :-) |
| 20:26 | <TabAtkins> | Losing internet isn't a common occurence anyway. This is the first time I've lost internet in the five years I've been living by myself, and it's only because something apparently went very wrong with the line hardware outside. |
| 20:26 | <TabAtkins> | Also: it means I get to hang out with my friend while I work (we work for the same company, and both work from home). |
| 20:41 | <hsivonen> | the reaction (and lack thereof) to Google's willful deviation from the RDFa spec is interesting |
| 20:42 | <TabAtkins> | There a link to an explanation of what they violate, hsivonen? |
| 20:43 | <hsivonen> | TabAtkins: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0124.html |
| 20:48 | <TabAtkins> | Hmm, I see. That's interesting. |
| 21:25 | <drunknbass_work> | i know when you draw you can change the ctm in canvas, but is there anyway to change an Image() and save the image already translated? |
| 21:26 | <Philip`> | drunknbass_work: You can draw a transformed image onto a canvas, and then either save the canvas or convert it back into an image with toDataURL |
| 21:26 | <Philip`> | if that's what you mean |
| 21:27 | <drunknbass_work> | well, im trying to do the least expensive stuff possible |
| 21:27 | <drunknbass_work> | i have to rotate anywhere from 0 -25 images and im afraid changing the ctm per redraw that much or more is costly |
| 21:28 | <Philip`> | Changing the CTM has basically zero cost |
| 21:28 | <drunknbass_work> | oh ok.. well if thats the case thats fine |
| 21:28 | <drunknbass_work> | im doing a game for mobile safari and pre and i already struggle for frps even redrawing nothing lol |
| 21:29 | <Philip`> | The only difference is that when you do drawImage, it's potentially going to be slightly faster if the image does not have to be rotated |
| 21:29 | <Philip`> | but that depends entirely on the implementation and what optimisations it performs |
| 21:29 | <Philip`> | so you'd just have to test it and see if there's a difference |
| 21:29 | <drunknbass_work> | but there is no other way to handle it right |
| 21:30 | <Philip`> | If each image is always rotated the same way, you could use document.createElement('canvas') and then drawImage onto that with all the transformations, and then do a simple straight untransformed ctx.drawImage(that_other_canvas, ...) onto the screen |
| 21:30 | <Philip`> | which might be faster or might be slower |
| 21:31 | <drunknbass_work> | think of tetris |
| 21:31 | <Philip`> | ...and just generate that_other_canvas once, and reuse it on every frame |
| 21:31 | <drunknbass_work> | the pieces can rotate but they all comeoff the same img file |
| 21:32 | <Philip`> | If each can only be rotated in four different directions, it would be reasonable to pre-compute all the rotations of all the images |
| 21:32 | <drunknbass_work> | yup |
| 21:32 | <Philip`> | and it's possible it might be a little bit faster that way, rather than drawing a rotated image each frame, or maybe not |
| 21:33 | <drunknbass_work> | the objects dont actually rotate during gameplay only when the pieces are laid out the first time |
| 21:33 | <drunknbass_work> | but even if they did rotate i guess itd make 0 difference |
| 21:34 | <drunknbass_work> | since i have to rotate them from original img state anyways |
| 21:38 | <franksalim> | drunknbass_work, if you are targeting mobile safari and pre, is using -webkit-transform and images instead of drawing to a canvas viable? |
| 21:39 | <drunknbass_work> | can you use webkit transform AND canvas? |
| 21:39 | <drunknbass_work> | if not, not, i already used divs and its a mess |
| 21:41 | <franksalim> | was it a mess because you weren't rotating the divs? were you using divs like a grid of blocks? |
| 21:42 | <Philip`> | I assume the thing you most want to optimise is the drawImage calls that you have to do per frame, and precomputing bitmaps that can be blitted directly onto the screen seems likely to be better than any run-time transformations |
| 22:37 | <hober> | http://jkemp.net/tag/hybi.html |
| 22:39 | <annevk42> | that's a whole lot of CSS and HTML for a few slides |
| 22:40 | <annevk42> | I guess the upside is that it works outside Opera... |
| 22:50 | <TabAtkins> | Bleh, that seems horrifying. You can accomplish slides *way* easier, without even relying on page-* properties. |
| 22:51 | <TabAtkins> | Just make html,body,.slide { height:100%; }, then tag each slide with an id and use hashchanges to navigate between slides. |
| 22:59 | <TabAtkins> | http://www.xanthir.com/:v3z <-- basic reimplementation of Kemp's slides using the above hack |
| 23:00 | <TabAtkins> | The slides are id'ed as #s1, #s2, etc. |
| 23:20 | <annevk42> | Hixie, shouldn't http://html5.org/tools/web-apps-tracker?from=3877&to=3878 be INVALID_STATE_ERR? |