| 00:00 | <zcorpan_> | having Hixie mark up status markers and what applies to authors or not is not useful use of his time... so if we can set up something that anyone can update it would be better |
| 10:55 | <ddfreyne> | The example of the "small" element (http://www.whatwg.org/specs/web-apps/current-work/#the-small) is confusing… |
| 10:55 | <ddfreyne> | If "small" is used to mark up small print, including copyright notices… why can the "copyright" class name not be used on "small"? |
| 10:56 | <ddfreyne> | (the "copyright" predefined class name is only applicable to p and span) |
| 10:57 | <annevk> | The spec is not done yet so you might have encountered an error. The best way forward is to e-mail whatwg⊙wo |
| 10:57 | <ddfreyne> | will do |
| 12:29 | <zcorpan_> | ddfreyne: just read http://stoneship.org/journal/2007/html5-sucks/ |
| 12:30 | <ddfreyne> | ah, neat |
| 12:30 | <ddfreyne> | the "sucks" is just there to catch attention ;) |
| 12:31 | <zcorpan_> | footnote: i think this is an open issue still |
| 12:32 | <zcorpan_> | note: there is class=note |
| 12:32 | <zcorpan_> | page, comment: this is what article is for |
| 12:32 | <ddfreyne> | class=note… yes |
| 12:33 | <ddfreyne> | zcorpan_: I'm against adding new elements like note/page/comment… i'd prefer the set of elements to be reduced rather than enlarged |
| 12:34 | <ddfreyne> | those are very big changes I'm proposing and they'll probably be ignored… |
| 12:34 | <zcorpan_> | i understand that you prefer that, but i don't understand why |
| 12:34 | <zcorpan_> | i don't think they'll be ignored :) |
| 12:35 | <zcorpan_> | consider this: would you prefer if html4 did the same 10 years ago? <div role="table"> instead of <table>? |
| 12:35 | <zcorpan_> | <div role="object"> |
| 12:35 | <ddfreyne> | table, object… are much more specific than <article> |
| 12:36 | <ddfreyne> | hm… sec |
| 12:37 | <ddfreyne> | <article> by itself doesn't have any article-specific attributes |
| 12:37 | <zcorpan_> | should there be? |
| 12:38 | <ddfreyne> | something like a hAtom subset converted to elements where appropriate (<article> instead of <div class="hentry">) would be useful |
| 12:38 | <ddfreyne> | I think it'd be useful |
| 12:39 | <zcorpan_> | yes... <article> is exactly like <div class="hentry"> aiui |
| 12:39 | <zcorpan_> | you can use <artile> for wrapping a blog post and inner <article>s for the comments |
| 12:40 | <ddfreyne> | I don't see why <article> is better than <div class="hentry"> though |
| 12:41 | <zcorpan_> | i'll discuss more in a bit, i have to run to the gym now |
| 12:41 | <ddfreyne> | I sound microformats-biased :) |
| 12:41 | <ddfreyne> | alright, seeya |
| 12:41 | <zcorpan_> | later |
| 13:38 | <mpt> | The only reason I can think of for having <article> is to prevent accidental search results when the search keywords are spread across multiple <article>s that happen to be shown on the same page |
| 13:40 | <mpt> | Because search engines can't know what <div class="some random value representing an article"> means, but they can know what <article> means |
| 13:41 | <mpt> | but, well, blah |
| 13:43 | <mpt> | Reducing the number of <div>s in the world is not a useful goal |
| 13:54 | <ddfreyne> | that problem could be solved with microformats as well |
| 13:59 | <ddfreyne> | (and I'm not saying everything can be solved with microformats) |
| 13:59 | <gsnedders> | how can it be saved with µf? |
| 13:59 | <gsnedders> | *solved |
| 14:00 | <ddfreyne> | class="hentry" on a block element that is an article |
| 14:02 | <mpt> | I'm <div class="hentry" id="the-8th"> I am, I am, I'm <div class="hentry" id="the-8th"> I am... |
| 14:05 | <ddfreyne> | Sorry… not following you there |
| 14:05 | <nlogax> | :D |
| 14:18 | <mpt> | http://en.wikipedia.org/wiki/I'm_Henery_the_Eighth,_I_Am |
| 14:24 | <ddfreyne> | ah, haha |
| 14:26 | <gsnedders> | ddfreyne: but people make up class names, someone might (oddly) use hentry. people don't make up element names (normally) |
| 14:34 | <mpt> | That's an argument against microformats in general, not against <article> in particular |
| 14:36 | <ddfreyne> | gsnedders: yeah, that's why I actually suggested something like role= |
| 14:36 | <ddfreyne> | (which is similar to class, but predefined, with clear semantic meanings for each value) |
| 14:37 | <ddfreyne> | I think it'd be better to not meddle with class… |
| 14:54 | <gsnedders> | how are unknown attributes treated? |
| 14:54 | <gsnedders> | %Text? |
| 15:00 | <Philip`> | ddfreyne: I think the selection of structural elements in HTML5 (and the lack of footnote, note, comment, etc) is partly justified by http://code.google.com/webstats/2005-12/classes.html - it's trying to cover all of the most common cases, though I guess the cutoff point is largely a subjective choice |
| 15:02 | zcorpan_ | is back |
| 15:22 | <zcorpan_> | ddfreyne: i think there are several reasons for using elements rather than attributes for article &c |
| 15:23 | <zcorpan_> | ddfreyne: (1) it's easier to author and maintain markup with element names instead of lots of divs |
| 15:24 | <zcorpan_> | ddfreyne: (2) if we continue reusing div for anything new this way we would end up with DivML 1.0 or something after a while |
| 15:25 | <zcorpan_> | ddfreyne: (3) it prevents the case where an element is both an article and nav at the same time, or where the attribute is placed on bogus places |
| 15:25 | <ddfreyne> | zcorpan_: (1) You could keep on adding new elements for anything that is used a lot |
| 15:26 | <ddfreyne> | zcorpan_: (2) using new elements breaks in some browsers, while role=... or class=... does not |
| 15:26 | <ddfreyne> | and I have no 3 yet |
| 15:26 | <zcorpan_> | ddfreyne: (4) it's more performant to process elements than attributes in the general case (look at the headings and sections section for how article is part of the document outline algorithm) |
| 15:27 | <ddfreyne> | I simply think the amount of new elements is too much |
| 15:28 | <ddfreyne> | I like <m> and <section>, but I don't think it's worth adding 10 more elements |
| 15:28 | <zcorpan_> | (2) i don't think it breaks anything (the content is still accessible as if the tags weren't there, no different from say <label>), it just isn't possible to style in some browsers |
| 15:29 | <ddfreyne> | Hmm… I remember someone mentioning a workaround for that in fact… I've never seen it though |
| 15:30 | <zcorpan_> | why is it better to use attributes instead of elements? as i said, it would complicate processing, so i don't think using attributes would make the language simpler in any way |
| 15:31 | <zcorpan_> | one workaround is to use xhtml5 :) another might be to fix up the dom with script afterwards |
| 15:32 | <ddfreyne> | Hm… what about the predefined class names, though… what is the reasoning for not putting them into a separate element? |
| 15:32 | <ddfreyne> | Hm, they are more like 'properties' of existing elements I suppose |
| 15:32 | <zcorpan_> | they can apply to multiple elements |
| 15:32 | <zcorpan_> | yeah |
| 15:34 | <zcorpan_> | it could be argued that we should combine all sectioning elements (except body) to just <section> and then use an attribute for what kind of section |
| 15:35 | <zcorpan_> | but i'm not sure what the advantage would be |
| 15:35 | <ddfreyne> | There's still the difference between <div> and <section> which isn't entirely clear |
| 15:36 | <ddfreyne> | If you could add a… say, type="header" attribute to <section>… the entire page would be <section>s, with very few divs |
| 15:36 | <zcorpan_> | indeed... i think this needs to be pointed out very explicitly in the spec... in a nutshell div doesn't affect the document outline |
| 15:36 | <ddfreyne> | so you end up replacing <div> by <section> which is pointless |
| 15:36 | <zcorpan_> | section is not intended to be a catch-all replacement of div |
| 15:36 | <ddfreyne> | clearly |
| 15:37 | <zcorpan_> | but i fear many authors will go "oh, section is the new div, i should replace all my divs with sections!" |
| 15:37 | <zcorpan_> | q.v. b->strong |
| 15:38 | <ddfreyne> | yeah |
| 15:38 | <ddfreyne> | I do believe many div's could be replaced by section's though |
| 15:38 | <zcorpan_> | sure |
| 15:40 | <zcorpan_> | here's an experiment: http://simon.html5.org/sandbox/html/w3c-home-in-html5 |
| 15:41 | <ddfreyne> | Yeah, I did something similar with my site a few days ago |
| 15:42 | <ddfreyne> | Perhaps I simply haven't used html5 enough to judge the use of new elements |
| 15:43 | <ddfreyne> | What is the reasoning for giving presentational elements a semantic meaning? |
| 15:43 | <zcorpan_> | there isn't much that can be used today in practice :) |
| 15:43 | <ddfreyne> | that too |
| 15:44 | <Hassman> | whow http://simon.html5.org/valid-html5.png with cat inside 8-) |
| 15:44 | <zcorpan_> | :) |
| 15:44 | <ddfreyne> | that's probably the biggest reason why I switched back… HTML4 is stable and predictable |
| 15:44 | Hassman | met__ |
| 15:44 | <zcorpan_> | ddfreyne: probably to not upset the semanticists or so |
| 15:45 | <ddfreyne> | wouldn't it have made more sense to deprecate the elements instead? |
| 15:45 | <zcorpan_> | that will make em and strong be the de facto italics and bold elements |
| 15:45 | <zcorpan_> | but they already are |
| 15:46 | <ddfreyne> | Redefining b, i, small, etc gives me the impression "b, i and small are no longer uncool, and you can use presentational markup again!" |
| 15:48 | <ddfreyne> | Hm… the use of <article> could actually bring back this old "subscription" feature IE5 had… |
| 15:48 | <zcorpan_> | see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-January/009060.html |
| 15:49 | <ddfreyne> | You'd bookmark a page, then tell IE to check whether the page had been updated or not… but that doesn't work on dynamic pages unless the actual content can be extracted |
| 15:50 | <ddfreyne> | which is possible with <article> (anything outside that could be ignored) |
| 15:50 | <zcorpan_> | indeed |
| 15:50 | <ddfreyne> | zcorpan_: ah, interesting… |
| 15:52 | <zcorpan_> | trying to force authors to use semantic markup doesn't work, they will instead misuse semantic elements for presentational purposes |
| 15:53 | <zcorpan_> | additionally, semantics is not an end of itself, it's more a means to achieve device independence |
| 15:53 | <ddfreyne> | zcorpan_: that raises the question… why have four elements instead now (i, em, b, strong) if the more "semantic" ones are supposed to replace the more "presentational" ones? |
| 15:53 | <ddfreyne> | (or the other way around) |
| 15:53 | <zcorpan_> | we already have 4. why forbid one pair of them? |
| 15:53 | <wilhelm> | Because they have different meanings. |
| 15:54 | <ddfreyne> | well, <i> and <b>'s meaning changed |
| 15:55 | <wilhelm> | Yes. To something that makes more sense. |
| 15:55 | <zcorpan_> | wilhelm: in practice, you can't differentiate between <i> and <em> in an app that extracts semantics, and the benefits of differentiating them on the consumer side is questionable |
| 15:56 | <zcorpan_> | so i'm with hsivonen (it took me a while though) |
| 15:56 | <ddfreyne> | How would WYSIWYG editors differentiate between <i> and <em>, and <b> and <strong>? |
| 15:56 | <zcorpan_> | they don't |
| 15:57 | <ddfreyne> | So they could use <b> for important text, and <strong> for bold? |
| 15:57 | <ddfreyne> | That doesn't seem to solve anything… |
| 15:57 | <zcorpan_> | you can use either for any purpose of why you want bold |
| 15:58 | <zcorpan_> | you want bold for a purpose, but most authors don't think about the purpose |
| 15:58 | <zcorpan_> | or they do but they don't want to mark up the purpose |
| 15:58 | <zcorpan_> | they just hit command-b |
| 15:59 | <zcorpan_> | and the reader gets the purpose because of the context |
| 15:59 | <zcorpan_> | search engines can't extract anything useful here |
| 15:59 | <ddfreyne> | I see… Why do <strong> and <b> still have different meanings, then? |
| 15:59 | <wilhelm> | In written Norwegian, titles of books, magazines, newspapers, movies, records, TV programs and plays are to be displayed in italics. |
| 15:59 | <zcorpan_> | ddfreyne: because Hixie isn't convinced yet, i think :) |
| 15:59 | <wilhelm> | Those italics are not emphasis. And they are not really presentational. |
| 16:00 | <zcorpan_> | wilhelm: indeed |
| 16:00 | <ddfreyne> | wilhelm: but italics there has a semantic meaning… it's not italics because it's pretty |
| 16:01 | <wilhelm> | When we have an element that does the job (<i>), there is no point in requring the author to use <span class='title-of-book'> or some other nonsense. |
| 16:01 | <wilhelm> | ddfreyne: Exactly. |
| 16:01 | <zcorpan_> | indeed |
| 16:01 | <zcorpan_> | seems we agree :) |
| 16:01 | <zcorpan_> | now i gotta go again |
| 16:01 | <ddfreyne> | seeya |
| 16:01 | <zcorpan_> | cya |
| 16:02 | <wilhelm> | Which is what the HTML5 spec says. <i> is used to markup “a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized”. |
| 16:03 | ddfreyne | nods |
| 16:05 | <ddfreyne> | You wouldn't write something like this either… the <span class="noun">title</span> of a <span class="noun">book</span> <span class="verb">is</span> <span class="adjective">italicized</span>. |
| 16:05 | <ddfreyne> | silly example really |
| 16:06 | <ddfreyne> | You just mark up what's necessary… marking up the title of a book as a separate class doesn't make sense unless you somehow want to do something with a list of book titles |
| 16:06 | <wilhelm> | No. I would write “<i>Menneskehetens rikdommer</i> av Leo Huberman er en bra bok.” |
| 16:07 | <ddfreyne> | which is pretty much why I don't like the introduction of header, footer, section, aside, article, nav, dialog, … because usually it's not necessary to explicitly mark them up that way |
| 16:08 | <wilhelm> | It might not be neccessary. But it is very useful. |
| 16:09 | <wilhelm> | Especially <article> and <section>. |
| 16:09 | <ddfreyne> | Apart from less keystrokes and readability… what is the use of <header> and <footer>? |
| 16:09 | <ddfreyne> | yeah, I like <article> and <section> |
| 16:12 | <wilhelm> | Standardization. I can tell my web browser to don't bother printing <header>s, <footer>s or <nav>s, because they are not useful on paper. |
| 16:12 | <ddfreyne> | But you could simply tell your browser to display the contents of <article> instead. |
| 16:14 | <wilhelm> | That is also possible, I guess. But standardization of commonly used classes of elements is useful anyway. |
| 16:15 | <wilhelm> | Both for page authors and browser vendors. |
| 16:16 | <ddfreyne> | Standardization for standardization's sake doesn't make a lot of sense though |
| 16:17 | <wilhelm> | Standardization makes it easier to write and parse documents. |
| 16:18 | <zcorpan_> | the use-case of <header> is mainly subheadings (that shouldn't be part of the document outline) |
| 16:18 | <zcorpan_> | "footer" was a very common class name |
| 16:18 | zcorpan_ | shouldn't be here |
| 16:18 | <ddfreyne> | Ahh, hm |
| 16:19 | <zcorpan_> | these elements also remove the need for skip links |
| 16:20 | <ddfreyne> | an <article> element would eliminate the need for skip links as well though |
| 16:21 | <zcorpan_> | <article> and <nav> mainly |
| 16:23 | <wilhelm> | Sure. But why _not_ standardize the most commonly used classes? footer is the most widespread class on the web. |
| 16:23 | <wilhelm> | http://code.google.com/webstats/2005-12/classes.html |
| 16:24 | <ddfreyne> | elementitis :) |
| 22:40 | <zcorpan_> | http://forums.whatwg.org/viewtopic.php?t=38#190 |
| 22:46 | <zcorpan_> | perhaps the spec should have a non-normative appendix that lists the differences between html5 and xhtml5 |
| 22:48 | <met__> | something like this appendix http://www.w3.org/TR/xhtml2/xhtml2-changes.html#a_changes ? |
| 22:48 | <zcorpan_> | heh |
