/irc-logs / w3c / #html-wg / 2007-05-11 / end

Options:

  1. # Session Start: Fri May 11 00:00:00 2007
  2. # Session Ident: #html-wg
  3. # [00:01] * Joins: Zeros (Zeros-Elip@67.154.87.254)
  4. # [00:25] * Quits: Sander (svl@71.57.109.108) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  5. # [00:29] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
  6. # [00:54] * Joins: mjs (mjs@17.255.105.149)
  7. # [00:57] * Quits: laplink (link@212.33.131.105) (Quit: Leaving)
  8. # [01:00] * Joins: laplink (link@212.33.131.105)
  9. # [01:02] * Quits: schepers (schepers@72.29.239.177) (Quit: Free at last!)
  10. # [01:08] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  11. # [01:12] <cying> hmmm, i feel neglected, no one commented on my chained classnames
  12. # [01:12] <cying> i was sure someone might comment
  13. # [01:13] * Joins: gavin_ (gavin@74.103.208.221)
  14. # [01:13] <MikeSmith> post a message on <i> vs <em> ... you'll get lots of replies
  15. # [01:14] <MikeSmith> I promise to post a +1 reply if you do
  16. # [01:15] <cying> haha
  17. # [01:15] <zcorpan_> cying: pointer?
  18. # [01:16] <cying> zcorpan_: http://lists.w3.org/Archives/Public/public-html/2007May/0929.html
  19. # [01:16] <Zeros> cying, support doesn't exist in IE6 though
  20. # [01:17] <Zeros> Is IE7's rule parser fixed for that?
  21. # [01:17] <cying> Zeros: oh @#%@#!#%!%@%
  22. # [01:17] <Zeros> cying, IE6 sees .foo.bar.baz {} as if it was .baz {}
  23. # [01:17] <Zeros> So it'd work, sort of. It'd just have unexpected behavior if you also had a .copyright elsewhere
  24. # [01:18] <cying> ahhh
  25. # [01:18] <Zeros> Personally I think role (or some such attribute) makes much more sense than class
  26. # [01:19] * Quits: tH (r@87.102.22.235) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
  27. # [01:19] <Zeros> There's no chance for collision that way, and we can make real claims on conformance. There's no way we can make a statement like "copyright is only allowed on foo element" in HTML5, it'd invalidate lots of existing content
  28. # [01:19] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
  29. # [01:19] <cying> ahhh
  30. # [01:20] <Zeros> Of course IE6 doesn't actually support [role=foo] either, so we don't gain anything on that front, heh.
  31. # [01:20] <hasather> Zeros: yea, multiple classes are supported in IE7
  32. # [01:20] <cying> oh cool!
  33. # [01:21] * Joins: sbuluf (rx@200.49.140.40)
  34. # [01:21] <zcorpan_> i don't see the use in having copyright being a predefined class name. what is there that browsers/markup consumers can do with it?
  35. # [01:22] <Zeros> we need a <copyright>
  36. # [01:22] <zcorpan_> Zeros: why?
  37. # [01:22] <jdandrea> I used it as a style hook (even with a former big-shot telco employer) but that's about it.
  38. # [01:22] <jdandrea> :)
  39. # [01:22] <Zeros> zcorpan_, because it's a very common feature of pages
  40. # [01:22] <Zeros> Most pages have a copyright
  41. # [01:23] <sbuluf> what's so wrong about role?
  42. # [01:23] <Zeros> zcorpan_, why have <p> ?
  43. # [01:23] * Quits: billmason (billmason@69.30.57.156) (Connection reset by peer)
  44. # [01:23] <sbuluf> <Zeros> zcorpan_, why have <p> ? <--in this wg, because of back compat. if we are talking about a hipotetically good content authoring language, we shouldn't
  45. # [01:24] <zcorpan_> Zeros: because it's useful for browsers and markup consumers to know where text is split up in paragraphs
  46. # [01:24] <Zeros> zcorpan_, and it's also useful to know what the meaning of different parts of the page
  47. # [01:24] <zcorpan_> Zeros: i don't see how a UA knowing that a piece of text is a copyright statement is useful for the UA
  48. # [01:25] <Zeros> Screen readers could skip it, parsers could parse it out when scraping
  49. # [01:25] <zcorpan_> Zeros: it depends on whether there is something useful you can do with the knowledge
  50. # [01:25] <jdandrea> Mmm. Where to draw the line. There should be a good litmus test for this sort of thing - when to prefer divining a new element vs. attribute vs. metadata.
  51. # [01:25] <jdandrea> Use cases then.
  52. # [01:25] <Zeros> jdandrea, the use cases are all over the web
  53. # [01:25] <Zeros> damn near every page has a copyright
  54. # [01:26] <Zeros> Lots of people use class="copyright"
  55. # [01:26] <Zeros> or some such variant for adding it to the footer
  56. # [01:26] <zcorpan_> copyrights being common does not imply that there is a use-case for UAs knowing what is a copyright statement
  57. # [01:26] <Zeros> That doesn't make sense
  58. # [01:26] <Philip`> That's just a use case for class="copyright" and CSS - why will content producers and consumers want something more than that?
  59. # [01:26] <Zeros> zcorpan_, you're stuck in the browser world
  60. # [01:26] <jdandrea> Is there dublin core metadata for copyright?
  61. # [01:27] <Zeros> there's lots of UAs that are *not* browsers zcorpan_
  62. # [01:27] <zcorpan_> Zeros: um, yeah, i know
  63. # [01:27] <hsivonen> Zeros: do you have non-browser consumer use cases for knowing what pieces of text are copyright notices?
  64. # [01:27] <Zeros> Screen readers could skip copyrights unless the person really cared, most people put a date in the copyright and parsers could pull that out
  65. # [01:27] <jdandrea> Hmm. http://dublincore.org/documents/dcmi-terms/#H2 (dateCopyrighted)
  66. # [01:28] <hsivonen> Zeros: are those use cases not satisfied by heuristics tied to "©" or "Copyright"?
  67. # [01:28] <Zeros> zcorpan_, what about feeds? Or books (those have copyrights) on amazon?
  68. # [01:28] <Zeros> hsivonen, What browser lets you do getElementByContentInSomeRandomNode ?
  69. # [01:28] <hsivonen> Zeros: I don't understand you question
  70. # [01:29] <hsivonen> Zeros: ooh. now I get it
  71. # [01:29] <Zeros> hsivonen, or styling, or parsing? What about a node that has a random &copy; in it that isn't a copyright such as one that talks about it?
  72. # [01:29] <hsivonen> Zeros: you just said you were talking about non-browsers
  73. # [01:29] <Zeros> You can't use a heuristic like that.
  74. # [01:29] <zcorpan_> Zeros: the use-case you have given is that screen readers can identify copyright statements and don't reveal them to the reader. i don't understand why this is wanted
  75. # [01:29] <Zeros> hsivonen, Screen readers use the DOM too though, lots of things use it that aren't really browsers
  76. # [01:29] <Philip`> Would screen readers find it better to have irrelevant material identified as copyright, or would it better to use <article> and <footer> and <nav> so they can jump to the relevant parts and ignore the rest?
  77. # [01:30] <Zeros> zcorpan_, Because it's not really meaningful to read it over and over?
  78. # [01:30] <Philip`> s/irrelevant material/copyright material which is irrelevant to the users of screen readers most of the time/
  79. # [01:30] <Zeros> Books have copyrights as well, so Amazon could use it
  80. # [01:30] <zcorpan_> Zeros: screen readers can skip a paragraph at the user's will
  81. # [01:30] <hsivonen> Zeros: why shouldn't aural users be made aware of copyright provenance if the author thinks it is worth mentioning it to visual users?
  82. # [01:30] <Zeros> zcorpan_, Then why again are we using <nav> ?
  83. # [01:30] <Zeros> or menu?
  84. # [01:30] <Zeros> those have no use cases either, we already have ul
  85. # [01:30] <zcorpan_> Zeros: besides, there is <header> and <footer>
  86. # [01:31] <Zeros> zcorpan_, <footer> doesn't imply anything, it's a general container
  87. # [01:31] <Zeros> that's like arguing we don't need <p> because we have <div>
  88. # [01:31] <zcorpan_> Zeros: it's the kind of content that you're likely to skip if you're on a screen reader
  89. # [01:31] <Zeros> What is the harm is having a copyright?
  90. # [01:32] <zcorpan_> i'm not saying there's any harm, i'm saying i don't see the use-case of defining the class name
  91. # [01:32] <Zeros> You all seem very against adding any element that adds meaning to the page, but come time to talk about adding some kind of new form control and you're all for it
  92. # [01:32] <zcorpan_> Zeros: what?
  93. # [01:33] <Philip`> As far as I can see, the problem is with adding "meaning" when there aren't good reasons why people would make use of that added meaning, to justify the cost of specifying/implementing/testing/learning/etc a new feature
  94. # [01:33] <Zeros> zcorpan_, A huge portion of HTML5 and web forms goes into adding new "application" features
  95. # [01:33] <Zeros> Not adding better meaning
  96. # [01:33] <zcorpan_> i don't think it's a good idea to add some kind of new form control if there's no real use-case for it
  97. # [01:34] <Zeros> zcorpan_, there's lots of use cases for copyright, I've already presented them, you shot them all down with "well you can do it another way"
  98. # [01:34] <Zeros> and the same is true of the new form controls
  99. # [01:34] <zcorpan_> Zeros: i could extract one use-case (screen readers could skip copyrights)
  100. # [01:34] <zcorpan_> please point out the others i missed
  101. # [01:35] <Zeros> zcorpan_, spiders could show them separately on the search results, or any kind of parser could utilize that information.
  102. # [01:35] <zcorpan_> ok, thanks
  103. # [01:36] <zcorpan_> come to think of it, google code search shows copyright along with code snippets
  104. # [01:37] <hsivonen> zcorpan_: and did they need markup for it? :-)
  105. # [01:37] <zcorpan_> although code usually simply have their copyright statments in comments
  106. # [01:37] <zcorpan_> hsivonen: no
  107. # [01:37] <Zeros> hsivonen, you don't really /need/ markup for any of this though
  108. # [01:37] <jdandrea> Metadata.
  109. # [01:37] <jdandrea> When I think copyright I keep thinking metadata.
  110. # [01:37] <Zeros> The visible copyright notice on the page is far more reliable than the meta tag anyway
  111. # [01:37] <Philip`> Do screen readers currently attempt to use some heuristic methods to skip parts of pages? If so, I think those would be good examples of use cases that people clearly want and that could be improved by better language support. I've no idea how to find that out, though
  112. # [01:37] <Zeros> That's true of all metadata, meta in general is crap since it's hidden
  113. # [01:38] <jdandrea> But ... it's not intended to be rendered. It's data about data. (?)
  114. # [01:38] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
  115. # [01:38] <zcorpan_> it seems like a heuturistics is a more accurate way to extract what is a copyright statement for consumers given the current web, and that would possibly include looking at class=copyright
  116. # [01:38] * Joins: Zeros (Zeros-Elip@67.154.87.254)
  117. # [01:38] <jdandrea> You can certainly cover a lot of ground that way.
  118. # [01:39] <Zeros> zcorpan_, similarly an <email> element would be very useful.
  119. # [01:39] <sbuluf> <haiku>
  120. # [01:39] <sbuluf> <employee>
  121. # [01:39] <Zeros> More meaningful elements need to be added to HTML.
  122. # [01:39] <sbuluf> <car>
  123. # [01:39] <Zeros> sbuluf, that's silly, and you know it. Stop with the straw man.
  124. # [01:39] <zcorpan_> Zeros: doesn't <a href=mailto:> imply email?
  125. # [01:40] <Zeros> zcorpan_, how often is the mailto not used to prevent spam? how often is some kind of encryption used?
  126. # [01:40] <Philip`> http://www.google.com/support/bin/answer.py?answer=29508 seems useful copyright use, with <link rel=license>, which probably is enough to handle the metadata cases already for search engines to use
  127. # [01:40] <zcorpan_> Zeros: um, what would your <email> element be good for?
  128. # [01:40] <Zeros> Philip`, I don't know about that
  129. # [01:41] <Zeros> zcorpan_, Any email being presented on a web page, a directory, a mail client, a search page
  130. # [01:41] <Philip`> zcorpan_: The spec could say that user agents MUST NOT use the addresses contained in <email> tags to send spam
  131. # [01:41] <zcorpan_> Zeros: wouldn't spam bots pick that up the same way they have picked up mailto:?
  132. # [01:41] <Zeros> zcorpan_, Why do you think microformats exist? Because HTML is *deficient* in implying email.
  133. # [01:41] <Zeros> err meaning
  134. # [01:41] <Zeros> zcorpan_, Possibly
  135. # [01:42] <Zeros> zcorpan_, Again, why are you so against adding meaningful elements?
  136. # [01:42] <zcorpan_> Zeros: i'm not
  137. # [01:42] <beowulf> is there a microformat for email?
  138. # [01:42] <Zeros> These /have/ use cases
  139. # [01:42] <zcorpan_> Zeros: i'm asking for use-cases
  140. # [01:42] <Zeros> They're visible on pages everywhere
  141. # [01:42] <Zeros> zcorpan_, what's the use case for footer?
  142. # [01:43] <zcorpan_> Zeros: not sure
  143. # [01:43] <Philip`> Is <email> meant to be used with obfuscated/encrypted email addresses that only a human can convert into a real address?
  144. # [01:43] <zcorpan_> Zeros: i can see clear use-cases for <article> and <nav> and <header>
  145. # [01:43] <Zeros> zcorpan_, what's the usecase for header?
  146. # [01:43] <beowulf> oh, duh, of course there is
  147. # [01:44] <zcorpan_> Zeros: sub-headings not being part of the document outline
  148. # [01:44] * Joins: ddailey (david_dail@24.144.172.117)
  149. # [01:44] <Zeros> zcorpan_, And who is that useful to?
  150. # [01:44] <Zeros> What screen reader or search engine uses that?
  151. # [01:44] <zcorpan_> <header><h1>foo</h1><h2>bar</h2></header> as opposed <h1>foo</h1><h2>bar</h2>
  152. # [01:45] <beowulf> use case for <header> and <footer> might be to read the data once for each page in a group of pages?
  153. # [01:45] <zcorpan_> Zeros: screen readers can navigate between sections and create a document outline, i think
  154. # [01:45] <Zeros> beowulf, We can use zcorpan_'s argument too, why not just use a class or an id?
  155. # [01:45] <sbuluf> would someone inform me if this discussion is limited to the existing web and what this WG is supposed to do, or if it is off topic, and about what a good content authoring language should be like?
  156. # [01:45] <Zeros> Or why not just use the heuristic that any two headers that come right after the other should be considered combined like that?
  157. # [01:46] <Zeros> I don't see what's wrong with adding elements for common parts of pages on the web
  158. # [01:46] <Zeros> Microformats are designed to add meaning, what's the resistance to doing the same with HTML?
  159. # [01:46] <zcorpan_> Zeros: a heading following another heading doesn't always imply sub-heading
  160. # [01:46] <Zeros> zcorpan_, And a &copy; or a footer doesn't always imply a copyright
  161. # [01:47] <zcorpan_> right
  162. # [01:47] * Parts: hasather (hasather@81.235.209.174)
  163. # [01:47] <ddailey> The discussion of copyright made me think of a couple of years ago -- I was writing an e-mail about copyright law. I concluded with three points (a), (b) and (c). My word processor automatically converted (c) to the copyright symbol for me. I figured the software was precognizant. http://srufaculty.sru.edu/david.dailey/copyright/uncopyrightable.htm
  164. # [01:47] <Zeros> heh
  165. # [01:48] <Philip`> One problem with adding elements is that it doesn't degrade gracefully, since you can't style unrecognised elements in IE6/7, so authors won't really want to use them
  166. # [01:48] <Zeros> Philip`, that's true for header, or footer, or anything then
  167. # [01:48] <Zeros> How is this different?
  168. # [01:48] <zcorpan_> Philip`: yeah, that's a problem
  169. # [01:48] <jdandrea> Light Reading: http://ln.hixie.ch/?start=1129948617&count=1
  170. # [01:48] <sbuluf> thank you very much.
  171. # [01:48] <zcorpan_> Zeros: it isn't different
  172. # [01:49] <jdandrea> Search for "I think one of the biggest problems at the W3C is that groups feel that to show progress they must release specifications with new features, instead of trying their best to not release anything unless it is absolutely necessary. ...
  173. # [01:49] <jdandrea> ... Tantek's got it right with his whole microformats thing. The best microformat is the one that doesn't introduce anything new at all, it just defines more specifically the semantics of existing elements."
  174. # [01:49] <Zeros> jdandrea, Eh, I don't know about that.
  175. # [01:49] <Zeros> The debate about role is hilarious too
  176. # [01:50] <Zeros> The comment that the role attribute allows namespaced roles really took the cake.
  177. # [01:50] <beowulf> a lot of the debates show that people want very different things, and think they can get them from the same wg
  178. # [01:50] <Zeros> We're reinventing HTML in the form of attributes!
  179. # [01:50] <Philip`> It's a problem for all the new structural elements, so that kind of problem (plus the cost of adding the feature) has to be balanced against the value, which I think is what's wrong with "adding elements for common parts of pages on the web" when people aren't convinced the cost/value balance is in the right direction
  180. # [01:50] <beowulf> which is maybe worrying
  181. # [01:51] <Zeros> Philip`, there's no cost, the value is apparent.
  182. # [01:52] <Philip`> Someone has to write the spec for the new feature, dozens of people have to implement it, other people have to write test cases, authors have to learn about it and understand how to use it correctly and make use of it
  183. # [01:52] <Philip`> Even if it's something very simple like just a new tag that's parsed the same as <div>, there still is a cost to adding it
  184. # [01:52] <Zeros> Of course
  185. # [01:53] <Zeros> The same as any other element we add
  186. # [01:53] <zcorpan_> Zeros: yes, it's the same as any other element we add
  187. # [01:53] <Philip`> so I think I disagree with "there's no cost"
  188. # [01:53] <Zeros> zcorpan_, what's the usecase for time?
  189. # [01:53] <Zeros> HTML5 adds that
  190. # [01:54] <Zeros> Or meter?
  191. # [01:54] <Zeros> What's the use of that to a screen reader or a search engine or anyone?
  192. # [01:54] <Hixie> the use case for <meter> is giving people a chance not to abuse <progress>
  193. # [01:54] <zcorpan_> Zeros: hmm, being able to disambuigate dates/times. apparently there is a need for that, cf microformats <abbr title> for the same thing
  194. # [01:55] <jdandrea> WRT time: "The primary use cases for these elements are for marking up publication dates e.g. in blog entries, and for marking event dates in hCalendar markup. Thus the DOM APIs are likely to be used as ways to generate interactive calendar widgets or some such."
  195. # [01:55] <Hixie> (if we just introduced <progress>, people would abuse it, since there's no other way to give a nice meter)
  196. # [01:55] <Zeros> zcorpan_, I don't see know needing to disambiguate that and email is different
  197. # [01:55] <Hixie> <time> i'm less convinced about
  198. # [01:55] <Philip`> About <time>, it says "The primary use cases for these elements are for marking up publication dates e.g. in blog entries, and for marking event dates in hCalendar markup"
  199. # [01:55] <Hixie> but it seems there's a lot of people writing times who stick spans around them
  200. # [01:55] <Philip`> Oops
  201. # [01:55] <Hixie> so...
  202. # [01:55] <jdandrea> np. :)
  203. # [01:56] <zcorpan_> Zeros: it isn't, it's just that there already is a way to disambiguate email, we don't need more ways to do the same
  204. # [01:56] <Zeros> Hixie, And there's a lot of people writing copyrights who stick an element around them
  205. # [01:56] <Zeros> The same is true of email.
  206. # [01:57] <Hixie> Zeros: yeah, hence class=copyright
  207. # [01:57] <Zeros> zcorpan_, HTML doesn't define that though
  208. # [01:57] <Philip`> Does <time> have advantages over using whatever microformats do for times?
  209. # [01:57] <Hixie> Zeros: e-mail addresses can be done using <a href="mailto:"></a>
  210. # [01:57] <zcorpan_> Zeros: no, the mailto: protocol defines it
  211. # [01:57] <Zeros> zcorpan_, I'm not sure how you can argue that using a heuristic on a link is a good way to do that. Should people use <a href="mailto:"> if they don't want it to be a link?
  212. # [01:57] <Hixie> Philip`: microformats (ab)use <abbr> for times
  213. # [01:58] <Zeros> Hixie, and if it's not supposed to be a link?
  214. # [01:58] <Zeros> Hixie, Or what if we want to select it from the DOM?
  215. # [01:58] <Hixie> Zeros: why would you not want it to be a link?
  216. # [01:58] <zcorpan_> Zeros: probably not, then they should simply use the email as text not in an element
  217. # [01:58] <Hixie> to select it from the dom, use .href or similar
  218. # [01:58] <Zeros> So we need a getElementsByContentInSomeRandomAttribute()
  219. # [01:58] <Zeros> Hixie, That implies searching every a in the entire document yourself
  220. # [01:59] <Hixie> Zeros: i'm not sure i understand your use case
  221. # [01:59] <zcorpan_> Zeros: it should be pretty easy to find what is an email address even without <email>. ask your nearest spam bot
  222. # [01:59] <Zeros> Hixie, It adds extra meaning to the page. Both screen readers, search engines and any kind of consumer can use it.
  223. # [02:00] <Zeros> zcorpan_, They're not trying to consume the document as a document though, they're parsing it as a giant text file.
  224. # [02:00] <Philip`> Ah, I guess that abuse of <abbr> is a problem for screen readers if they try reading out the expanded format, and maybe the title tooltip is an undesired side-effect, and there's not any other convenient elements you could hang an alternate version of the date off of, hence the value of <time>
  225. # [02:00] <Hixie> Zeros: that's not a use case
  226. # [02:00] <Zeros> Hixie, I'm not sure what you mean? What's the usecase for footer?
  227. # [02:01] <Hixie> Zeros: a use case is something like "i want it to be possible for people to click on a link and open a mail program with my address filled in"
  228. # [02:01] <Hixie> Zeros: the use case for <footer> is stylistic, mostly -- class="footer" is one of the most used class names
  229. # [02:01] <Hixie> (according to my multi-billion document surveys, anyway)
  230. # [02:02] <Philip`> If it's just stylistic, that doesn't sound much like a use case that isn't already satisfied by 'class'
  231. # [02:02] <Zeros> yes
  232. # [02:02] <sbuluf> hixie, slightly unrelated: how many <blink>s in those documents?
  233. # [02:02] <Hixie> Philip`: indeed
  234. # [02:02] <jdandrea> As currently defined, the footer "typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like." So in a sense there's a place reserved for the copyright, no?
  235. # [02:02] <Hixie> Philip`: but <div class="footer"> isn't as neat as <footer>
  236. # [02:02] <Hixie> Philip`: "pave the cowpaths" and so on
  237. # [02:02] <Zeros> Fighting against copyright when footer is there for stylistic reasons doesn't make sense hixie
  238. # [02:02] * Hixie isn't fighting against copyright
  239. # [02:03] <beowulf> but you could possibly add to that use case that a <header> and <footer> can be ignored by a screen reader on the 2, 3, 4 ... pages with those tags at a url ?
  240. # [02:03] * zcorpan_ isn't either
  241. # [02:03] * zcorpan_ is asking for use-cases
  242. # [02:03] <Zeros> zcorpan_, the same as footer then
  243. # [02:03] * Quits: marcos (chatzilla@131.181.148.226) (Ping timeout)
  244. # [02:03] <zcorpan_> Zeros: ok, thanks
  245. # [02:03] <Philip`> sbuluf: I saw <blink> in something like half a percent of some very small statistically-insignificant nonrandom sample of pages
  246. # [02:03] <Hixie> i've already added class=copyright as a magic value to the spec. i'm not sure what an element would do, because it seems like there are multiple elements that might make sense for a copyright -- small, p, footer, address, span, a...
  247. # [02:03] <sbuluf> ohillip, your page collection is biased, and relatively small, right?
  248. # [02:04] <Hixie> sbuluf: quite a few, but not in the top 10
  249. # [02:04] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
  250. # [02:04] <Hixie> sbuluf: more than many actual valid html elements
  251. # [02:04] * Joins: Zeros (Zeros-Elip@67.154.87.254)
  252. # [02:04] <Zeros> Hixie, I'm not sure predefined class names are a good idea, we can't enforce them
  253. # [02:04] <sbuluf> hixie, if html5 has to document the web, what's the rationale for not including it then?
  254. # [02:04] <Hixie> Zeros: we can't enforce anything
  255. # [02:04] <Zeros> They also smell of reinventing HTML in the form of attributes
  256. # [02:05] <Zeros> We could have class="paragraph"
  257. # [02:05] <Philip`> I don't think I see why footers need <footer> while copyrights just need <div class="copyright">, when the use cases seem the same for both... Is it just some arbitary cutoff point of popularity?
  258. # [02:05] <Hixie> sbuluf: <blink> will be defined in due course (in the rendering section), along with all the other oft-used presentational elements
  259. # [02:05] <Philip`> sbuluf: It is both
  260. # [02:05] <Hixie> Philip`: the point is that footers are always block-level
  261. # [02:05] <Zeros> Hixie, You're defining what a conforming document is. How can you define that a class (that may already be in use in a lot of places) is only allowed on X elements in a conforming document?
  262. # [02:05] <sbuluf> hixie, oh thanks, i thought i saw people saying it would not be included
  263. # [02:06] <Hixie> Philip`: whereas copyrights are put all over the place -- inline, in blocks, in aside blocks, in multi-paragrph blocks, in links, etc
  264. # [02:06] <sbuluf> philip, thanks, nonetheless. hixie's docs are way bigger and more general.
  265. # [02:06] <Zeros> Hixie, A definition may be lots of different things as well, why do we need dfn instead of class="definition" ?
  266. # [02:06] <Hixie> Philip`: so it isn't clear how to define a single element for copyrights
  267. # [02:06] <Hixie> Philip`: see the code.google.com/webstats survey -- i mention copyright there as being one of the things i don't know how to handle
  268. # [02:07] <Hixie> Zeros: the class="" thing is still very much in the air
  269. # [02:07] <Hixie> Zeros: i'm not sure really what we should do with it
  270. # [02:07] <Hixie> Zeros: i'm thinking we should drop it, maybe, or change the way it's defined, not sure
  271. # [02:07] <zcorpan_> Zeros: <dfn> is for a defining *term*, not for the definition, and we're not adding <dfn> it has been in html since 1992
  272. # [02:07] <Philip`> sbuluf: There's a point at which larger samples are meaningless because you can work out the statistical error for any sample size and be happy if that error is small enough and then not bother looking at more data :-)
  273. # [02:07] <Hixie> Zeros: <dfn> was in HTML4, i didn't add it :-)
  274. # [02:07] <Zeros> zcorpan_, <copyright> is for marking up a *copyright*
  275. # [02:07] <ddailey> Hixie: the data you are talking about and http://code.google.com/webstats/ are one and the same? I have been curious about that.
  276. # [02:07] <Zeros> Hixie, It was an example and you got the point. :)
  277. # [02:08] <zcorpan_> Zeros: <copyright> wasn't present in previous versions of html
  278. # [02:08] <Hixie> Zeros: i don't know that <dfn> should be an inline element necessarily, though it makes more sense since a term is always a short piece of text
  279. # [02:08] <Zeros> zcorpan_, And neither was output, but it requires it's own element, and so does time or whatever
  280. # [02:08] <Hixie> Zeros: certainly a term is more likely to be inline than a copyright is
  281. # [02:09] <Hixie> ddailey: the stats on that site are one set of stats, yeah. i've seen done much bigger surveys to address other aspects of the language design
  282. # [02:09] <Zeros> Hixie, I'm very against adding predefined class names. Elements make much more sense to me. The whole namespaced role attribute is a huge failing point in my opinion. It's very visible as an Inner platform effect problem to me.
  283. # [02:09] <zcorpan_> Zeros: you keep mentioning that new elements have been included. you think use-cases weren't analysed for each and every new feature that was added before it was added?
  284. # [02:09] <ddailey> thanks
  285. # [02:10] <Hixie> Zeros: our opinions aren't really relevant, it's the use cases, technical arguments, and experience that matters
  286. # [02:10] <Zeros> zcorpan_, I think the use cases for them are not more important than the use cases for copyright or email or date though
  287. # [02:10] <Hixie> anyway, i have work to do :-)
  288. # [02:10] <Hixie> bbiab
  289. # [02:10] <zcorpan_> Zeros: that might well be the case
  290. # [02:10] <Zeros> zcorpan_, Would be be against a <date> ?
  291. # [02:10] <Zeros> you*
  292. # [02:11] <zcorpan_> yes, there is <time> for that already. :)
  293. # [02:12] <Zeros> Eh, there's already a <ul> for <menu> though, one is just more specific. :)
  294. # [02:12] <Zeros> Not all dates involve time and vice versa
  295. # [02:12] <zcorpan_> <time> can contain either date or time, or both
  296. # [02:12] <ddailey> the dates which do not involve time grow on date trees?
  297. # [02:13] <zcorpan_> Zeros: <menu> is for context menus and menu toolbars, mostly
  298. # [02:13] <Zeros> zcorpan_, I'm not sure that's a valid argument against date though. How do you know (as a person writing code) the difference between those kinds of dates?
  299. # [02:13] <Zeros> You parse out each and every one to search for them?
  300. # [02:14] <zcorpan_> Zeros: i don't understand the question
  301. # [02:14] <Zeros> zcorpan_, How do you differentiate between date and time <time> elements?
  302. # [02:14] <zcorpan_> Zeros: oh. that's defined in the spec
  303. # [02:14] <Zeros> zcorpan_, Right, there's an attribute, now is there a getElementsBySomeRandomAttribute() ?
  304. # [02:15] <Zeros> There's your use case right there. I want to be able to get all the dates in a document without getting every single date and time and scanning each one.
  305. # [02:15] <ddailey> I see tags like <date>, <time> <address> <location> <latitude> <copyright> <author> and I think of real world inference and automated reasoning
  306. # [02:16] <ddailey> Two <date> s are elements on a time continuum that motivates inference about before and after
  307. # [02:16] <zcorpan_> Zeros: so you want <time> to be split up to two elements because you don't want to process times when looking for dates?
  308. # [02:17] <Zeros> zcorpan_, I want them to be split up because they are different in meaning, but you don't want to hear that, you want use cases that about about applications.
  309. # [02:17] <Zeros> are about*
  310. # [02:17] <Philip`> Zeros: What's wrong with using getElementsByTagName('time') and then filtering the list?
  311. # [02:17] <zcorpan_> Zeros: i don't see them being very different, though
  312. # [02:18] <Philip`> (You can just check the .date or .time DOM attribute to see what it's got)
  313. # [02:18] <Zeros> Philip`, That's a lot of parsing to do something that should be simple
  314. # [02:18] <Zeros> well, processing, parsing is a bad word
  315. # [02:19] <zcorpan_> ok, so you want <time> to be split up in two elements because processing both date and time when you only want to look for dates is too much processing?
  316. # [02:19] <Philip`> You don't have to do parsing - just getElementsByTagName('time').filter(function(x){x.date!==null})
  317. # [02:20] <zcorpan_> you think you will notice a difference in processing time?
  318. # [02:20] <Philip`> (Er, can you do filter on that kind of list? It'd be something similar anyway)
  319. # [02:20] <Zeros> zcorpan_, I want them to be split up because they're different in meaning, but that's not a valid use case to you guys. :)
  320. # [02:20] <Hixie> Zeros: if you have <time> and <date>, how do you distinguish between a time with a timezone and a time without?
  321. # [02:21] <Zeros> Hixie, An attribute. Both are times.
  322. # [02:21] <Zeros> Hixie, A time may occur on any date, and date has no implicit time.
  323. # [02:21] <Hixie> Zeros: if you have <time> and <date>, how do you distinguish between a date indicating a year and a date indicating a month?
  324. # [02:21] <Hixie> the distinction between times and dates is artificial
  325. # [02:21] <Zeros> Hixie, Both are dates, there's no implicit difference there
  326. # [02:22] <Hixie> Zeros: "january" and "1997" are both dates, but "17:01" and "1970-01-01" are not both times?
  327. # [02:22] <Zeros> Hixie, 1970 01 01 is a date, there's no time in that.
  328. # [02:23] <Zeros> 17:01 is a time
  329. # [02:23] <Philip`> It's the time period from early midnight to late midnight on that day
  330. # [02:23] <Hixie> Zeros: 1970-01-01 is a 24 hour period, just like 17:01 is a one minute period
  331. # [02:23] <Philip`> 17:01 is the time period from the start of 17:01 to almost 17:02
  332. # [02:23] * Philip` doesn't see a significant distinction either
  333. # [02:24] <ddailey> does "yesterday" in an 18th century text have any meaning?
  334. # [02:24] <zcorpan_> ddailey: yes. does it warrant its own element? probably not :)
  335. # [02:24] <Zeros> hah
  336. # [02:25] <Zeros> I love the <car> argument
  337. # [02:25] <Hixie> Philip`: Zeros and us both have valid points -- you can cut times and dates any number of ways. timezones, repeating times, ranges, moments, etc -- <time> in HTML5 only handles the cases that are commonly seen on the web, according to the research i did
  338. # [02:25] <Zeros> Makes it very easy to dismiss anything
  339. # [02:25] <Hixie> this is why you can't make arguments based on opinions
  340. # [02:25] <Hixie> it has to be based on research
  341. # [02:25] <zcorpan_> Hixie: indeed
  342. # [02:26] <Zeros> Hixie, That's not particularly useful for anyone outside google ;)
  343. # [02:26] <Hixie> Zeros: lucky for us that we have googlers on the list, then :-)
  344. # [02:26] <Zeros> Considering your research cannot be duplicated or verified, I'm not sure I really count that as formal research at all.
  345. # [02:26] <Zeros> It might as well be made up
  346. # [02:26] * Hixie specifically quit opera and came to work for google because he wanted access to this data, for what it's worth
  347. # [02:26] <Hixie> Zeros: it might
  348. # [02:27] <Hixie> Zeros: but then if you don't trust my integrity, you have bigger problems that whether or not <date> and <time> are in the spec
  349. # [02:27] <Hixie> Zeros: i encourage you to find a way to get the data, like i did
  350. # [02:27] <Philip`> If there was some way to get a uniform random list of web pages, you could check a small sample pretty easily, and make sure the rough pattern matches the previously published results
  351. # [02:27] <Hixie> ideally somewhere other than google, so that we can have independent backup for the research
  352. # [02:27] <Philip`> (or non-uniform random but biased in the same way as the original sample)
  353. # [02:28] <Zeros> Philip`, The web is a failure in that manner though
  354. # [02:28] <ddailey> hixie: can't you just publish a few more excerpts from time to time -- sort of in serial installments? :)
  355. # [02:28] <Hixie> ddailey: what would you want me to publish?
  356. # [02:28] <Zeros> Hixie, I'm not sure that's possible without writing an entire search engine; So, can you parse the web and find class=".*?email.*?" ?
  357. # [02:29] * zcorpan_ should go to bed now, will talk about html5 for students in the morning
  358. # [02:29] <ddailey> hixie: all the news that's fit to print
  359. # [02:29] <ddailey> cooccurrence data would be sorta fun
  360. # [02:29] <Hixie> zeros: "email" was the 380th most common class in my sample of several billion pages last september
  361. # [02:29] * Parts: zcorpan_ (zcorpan@84.216.42.208)
  362. # [02:30] <Zeros> Hixie, And copyright was?
  363. # [02:30] <ddailey> a bit more detail on what goes on inside the <script> tag
  364. # [02:30] <Hixie> Zeros: 7th
  365. # [02:30] <Zeros> Hixie, hmm, interesting.
  366. # [02:31] <Zeros> Not sure that's actually vindictive of anything though. <div class="footer"><span>&copy;... #footer span {} works just as well. And the most common use case for classes is styling, not meaning.
  367. # [02:31] <Hixie> footer was 1st
  368. # [02:31] <Zeros> How about left and right?
  369. # [02:32] <Hixie> left was 17th, right was 13th
  370. # [02:32] <Zeros> more pages with a right hand column I guess
  371. # [02:32] <Hixie> yeah, left and right inspired <aside> and <nav> (amongst others)
  372. # [02:33] <Zeros> I still think adding proper elements for discreet common page components would be useful for deriving meaning from documents.
  373. # [02:33] <Hixie> i agree
  374. # [02:33] * Quits: laplink (link@212.33.131.105) (Quit: This computer has gone to sleep)
  375. # [02:34] <Hixie> hence the new or repurposed <footer>, <header>, <article>, <menu>, <small>, <nav> elements
  376. # [02:34] <Zeros> Hixie, So if you were going to compare <copyright> to class="copyright" what do you see as the disadvantage to the former?
  377. # [02:34] <Hixie> which covers more than half the top 10 classes
  378. # [02:35] <sbuluf> a new element vs. attribute vs. metadata. <--wouldn't this be worthy of a rationale page in some wiki?
  379. # [02:35] <sbuluf> at least for some sort of faq
  380. # [02:35] <Hixie> feel free to write one up
  381. # [02:35] <Hixie> Zeros: well, designing an element needs information on the way you'd expect it to be used. for example, you'd need to know whether it's going to be a block or inline
  382. # [02:36] <Hixie> Zeros: as mentioned on the webstats page, i considered <copyright>, but i couldn't work out how to design it
  383. # [02:36] <Zeros> sbuluf, I didn't mention meta data specifically since I think it's a huge reliability problem as shown by keywords or description.
  384. # [02:36] <Hixie> Zeros: should it be block? inline? metadata in the head? an attribute? a link?
  385. # [02:37] <Zeros> Hixie, Speaking of which, on that same line of thought, combined block/inline containers like del are out?
  386. # [02:37] <sbuluf> zeros, *you* didn't. but some else did. and i just did as well. *you* meantime (and everyone else), did not answer wat iu asked before, hence, marginalized me from the whole discussion.
  387. # [02:38] <Zeros> sbuluf, My apologies.
  388. # [02:38] <sbuluf> np
  389. # [02:38] <Hixie> Zeros: <del> and <ins> are pains in the ass, but right now the spec allows them. the content models for them are hella complicated.
  390. # [02:39] <Hixie> due to their transparent nature
  391. # [02:39] <Zeros> Hixie, I'd say inline considering the most common use case for it would end up in the line of <footer><copyright>...
  392. # [02:39] <Hixie> Zeros: what research are you basing that on?
  393. # [02:40] <Hixie> Zeros: if there's one thing i've learnt from the web, it's don't assume what authors are doing. they seem to do things you wouldn't expect, imho.
  394. # [02:40] <Zeros> Hixie, That the copyright on google, yahoo, deviantart, myspace, msn, w3.org, et al. are in the footers?
  395. # [02:40] <Zeros> I'm sure I could compile a rather lengthly list of pages that have a copyright in the footer
  396. # [02:40] <Hixie> Zeros: in the case of http://www.google.com/, i'd say it's not a footer, it's a paragraph of its own. thus it would be block-level.
  397. # [02:41] <Hixie> Zeros: it's not "pages that have a copyright in the footer" that we need, it's a neutral study of randomly selected pages, and for each one, a determination of what the closest match to the existing markup is
  398. # [02:41] <Zeros> Hixie, It's at the end of every page, it's a footer by definition.
  399. # [02:41] <Hixie> Zeros: yes, but it's its own block
  400. # [02:41] <Philip`> You could make a rather lengthy list of pretty much any feature at all, given how many pages there are to choose from :-)
  401. # [02:42] <Philip`> (e.g. count the number of pages using <footer> already)
  402. # [02:42] <Zeros> Philip`, It's the counter evidence pages which would be relevant. How many pages don't place the copyright at the end of the document?
  403. # [02:42] <Hixie> Zeros: with the dozens of billions of pages on the web, you can find millions of pages to prove anything
  404. # [02:43] <Hixie> e.g. i can give you over 3 million pages that use id="_ctl1_hlEmailFriend"
  405. # [02:43] <Zeros> Hixie, I'm not sure how it being it's own block is an argument against that though. Google's markup sucks. <footer><copyright> is problematic there how?
  406. # [02:44] <Philip`> http://www.whatwg.org/specs/web-apps/current-work/ - that has copyright information not in a footer
  407. # [02:44] <Zeros> That gives it the meaning that's the document footer (which it is) and that it's the copyright (which it is)
  408. # [02:44] <Hixie> Zeros: that's the wrong question. the question is, what's the problem that you're trying to solve?
  409. # [02:44] <Zeros> Hixie, Differentiating the copyright from the rest of the document in a meaningful way. Reducing the need for attributes like role.
  410. # [02:44] <Hixie> Zeros: if the problem is "people are using a class right now, so it makes sense to give them an element so that their pages are shorter and neater", then you wouldn't want to go from <p class="copyright"> to <footer><copyright>, because that would be way longer
  411. # [02:45] <Zeros> Or predefined class names as the case may be.
  412. # [02:45] <Hixie> Zeros: why is differentiating the copyright from the rest of the document in a meaningful way a goal?
  413. # [02:45] <Hixie> Zeros: is there some use for the copyright?
  414. # [02:45] <Zeros> Hixie, Why is adding <aside> better than class="left" ?
  415. # [02:46] <Hixie> Zeros: because it is shorter, and allows people who come to edit the page later to understand the markup much quicker than if they had to learn all the site's custom classes
  416. # [02:46] <Hixie> Zeros: and because it means you can switch it to the right hand side without changing all your class names
  417. # [02:46] <Hixie> (or confusing yourself and those who follow you)
  418. # [02:46] <Zeros> Hixie, <copyright> is shorter than <p class="copyright">, how is that even a relevant argument though...
  419. # [02:47] <Hixie> if you are replacing <p class="copyright"></p> with <copyright></copyright>, then that argues for a block-level element (and it isn't shorter, anyway)
  420. # [02:47] <Zeros> I'm not sure how length should be considered
  421. # [02:47] <Hixie> length is usually a red herring, but it can be a guide
  422. # [02:47] <Hixie> something shorter is usually simpler
  423. # [02:47] <Hixie> and thus easier to understand
  424. # [02:47] <Zeros> For that I guess I could argue for <copy>
  425. # [02:47] <Zeros> Which has all kinds of translation problems, but it's shorter!
  426. # [02:48] <Hixie> right. but that argues for a block-level element, not inline
  427. # [02:48] <Philip`> If I could work out how to type in Unicode, I'd suggest <{the Unicode copyright symbol}> which is only one character
  428. # [02:48] <Hixie> the point i'm trying to make is that if you really want to work out what to do with copyright, then you have to work out why and how people are using it today
  429. # [02:48] <Hixie> only then can you really make a good design decision
  430. # [02:49] <Zeros> Hixie, Either way, I see a real use case for copyright within the document as a means by which to differentiate it from the rest of the document for a screen reader (skip), a search engine (search by copyright?)
  431. # [02:49] <Hixie> note that it's possible that we've already addressed the need that class="copyright" handles -- if people are just doing that so they can style it, then <small> in HTML5 already addresses their need
  432. # [02:49] <Hixie> Zeros: right, but for that we already have <small>
  433. # [02:50] <Zeros> Hixie, Why does the text need to be smaller?
  434. # [02:50] <Hixie> Zeros: in practice, since copyrights are at the bottom, they don't need to be skipped; if they did, the <article> and <footer> elements already provide the hook for that
  435. # [02:50] <Philip`> (http://canvex.lazyilluminati.com/misc/copyright.html is kind of relevant for seeing what some people use class="*copyright*" for - mostly they actually put copyright notices in it - though it doesn't help with knowing where on the page it goes...)
  436. # [02:50] <Hixie> Zeros: also, google already does license search, and doesn't need a clear copyright element to do it
  437. # [02:50] <Zeros> Hixie, Ah, now you're arguing the same thing I did. Why are copyrights at the bottom? ;)
  438. # [02:50] <Hixie> Zeros: so the search engine use is apparently not true
  439. # [02:50] <Hixie> Zeros: <small> is redefined in HTML5, see the new definition
  440. # [02:50] <Zeros> So you agree that a copyright is probably in the footer?
  441. # [02:51] <Zeros> Hixie, I know, how many pages use small right now?
  442. # [02:51] <Hixie> a lot
  443. # [02:51] <Zeros> And then them for presentational reasons?
  444. # [02:52] <Hixie> ...?
  445. # [02:52] <Zeros> err, and in them*
  446. # [02:52] <Hixie> i don't understand the question
  447. # [02:52] <Zeros> How many of the uses of <small> have to do with meaning and how many are just for making the font a little smaller?
  448. # [02:53] <Hixie> no idea
  449. # [02:53] <Hixie> in HTML4 <small> was presentational only, so presumably, all of them
  450. # [02:53] <Zeros> um, Where's the research on that then?
  451. # [02:53] <Zeros> That sounds like a huge mistake. You're making every page on the web that uses small have new meaning now...
  452. # [02:53] <Hixie> no
  453. # [02:53] <Hixie> all the pages on the web are not HTML5
  454. # [02:53] <Zeros> Oh, so you're saying that HTML5 documents have different meaning than HTML4 ones?
  455. # [02:54] <Hixie> i'm saying that anyone who wrote a valid HTML4 document still has a valid HTML4 document
  456. # [02:54] <Hixie> HTML5 doesn't change that
  457. # [02:55] <Zeros> Hixie, So screen readers and browsers that want to extract meaning need a switch to tell if it's HTML5 or not?
  458. # [02:55] <Philip`> (http://canvex.lazyilluminati.com/misc/email.html for class="*email*" - only about two actually use it around an email address)
  459. # [02:55] <Hixie> Zeros: no, they need heuristics to tell if the page is conforming or not.
  460. # [02:55] <Hixie> Zeros: but they need that anyway -- most pages aren't conforming
  461. # [02:56] <Zeros> Hixie, An HTML5 and a HTML4 document look identical if you don't use new features.
  462. # [02:56] <Hixie> Zeros: yup
  463. # [02:56] <Zeros> Hixie, So how can you reliably extract meaning?
  464. # [02:56] <Hixie> you can't
  465. # [02:56] <Zeros> Hixie, And in that same line, so HTML6 can just redefine what <small> means again and then say that a HTML6 document is not a HTML5 document?
  466. # [02:56] <Hixie> you can only extract meaning from pages you know are conforming
  467. # [02:56] * Quits: zdenko (zdenko@84.255.203.169) (Quit: zdenko)
  468. # [02:56] <Hixie> the current state of the web is a disaster as far as that goes
  469. # [02:57] <Zeros> Hixie, HTML4 becomes non-conforming with HTML5 though
  470. # [02:57] <Zeros> since the <small> is useless
  471. # [02:57] <Zeros> The same is true of <i> or <b>, you're saying they have meaning, but only in a HTML5 document near as I can tell.
  472. # [02:58] <Hixie> i don't really understand the problem with that
  473. # [02:58] <Zeros> And then you say that HTML4 and HTML5 look the same, and don't have a differentiating feature, so how is that meaning not lost?
  474. # [02:58] <Hixie> this is a straw man argument
  475. # [02:58] <Hixie> most pages on the web are completely non-conforming
  476. # [02:59] <Zeros> You're saying HTML4 documents are still conforming in the HTML5 world, but they're not.
  477. # [02:59] <Zeros> HTML4 document that used small for small text is not conforming in HTML5.
  478. # [02:59] <Hixie> no, no
  479. # [02:59] <Hixie> consider this from the top:
  480. # [03:00] <Hixie> let's simplify and say that there are two classes of documents right now: those that use semantic markup and those that don't
  481. # [03:00] <Hixie> those that do have "meaning", and those that don't, well, don't.
  482. # [03:00] <Hixie> those in the latter category are those that use <i>, <b>, <small>. but in the previous versions, those elements had _no_ meaning (beyond the presentational meaning)
  483. # [03:00] <Zeros> Yes, so they were conforming.
  484. # [03:00] <Hixie> those in the former category don't use presentational elements
  485. # [03:01] <Hixie> now, in the html5 world, we've given "semantic" meaning to those three elements, alongside their presentational meaning
  486. # [03:01] <Zeros> So how do you know the difference between the semantic ones and the presentational ones?
  487. # [03:01] <Hixie> the documents in the first category, those with meaning, still have the same meaning, and are unchanged
  488. # [03:02] <Hixie> those in the second category, those without meaning, now have some minor meaning, possibly non-sensical
  489. # [03:02] <Zeros> And the ones without meaning, which look just like a HTML5 document, have no meaning, and can't be differentiated from (non)conforming HTML5.
  490. # [03:02] * Parts: ddailey (david_dail@24.144.172.117)
  491. # [03:03] <Zeros> And you don't see any problem with adding non-sensical meaning to existing pages?
  492. # [03:03] <Hixie> so, the above was the transition from html4 to html5. now, consider purely html5 documents.
  493. # [03:03] * Quits: mjs (mjs@17.255.105.149) (Quit: mjs)
  494. # [03:03] <Zeros> A purely HTML5 document looks just like a HTML4 document. Consider a purely HTML4, conforming document, that used <b> for presentation.
  495. # [03:04] <Hixie> in html5, we have conforming documnets (those using the elements correctly) and non-conforming ones (those using the elements incorrectly)
  496. # [03:04] <Zeros> It's valid, the meaning is correct, b was never deprecated, it has perfect meaning in HTML4. Now you're adding non-sense.
  497. # [03:04] <Hixie> there's no way to distinguish them
  498. # [03:04] <Hixie> programatically
  499. # [03:04] <Zeros> And that's not a problem?
  500. # [03:04] <Hixie> so a user agent has to have heuristics if it wants to detect one from the other (e.g. google does this)
  501. # [03:05] <Zeros> Google can tell the difference between a presentational or a meaningful <b>?
  502. # [03:05] <Zeros> How about screen readers?
  503. # [03:05] <Hixie> but in fact, this has always been the case, because there is a third category of documents in the html4 case that i omitted to mention earlier: documents that look like they use semantic markup, but actually are ignoring their meaning and just using them for presentational effect
  504. # [03:05] <Hixie> e.g. using <blockquote> for indent
  505. # [03:06] <Hixie> or <table> for layout effects
  506. # [03:06] <Zeros> And the fourth category that used valid markup and presentational elements too since they had no meaning.
  507. # [03:06] <Hixie> and there was no way even then to tell the html4 documents with meaning from the html4 documents without meaning
  508. # [03:06] <Zeros> And there's no way to tell a HTML5 document with meaning, from one without from one that's HTML4 that used <b> for presentation
  509. # [03:07] <Hixie> in conclusion: we're not actually changing anything, except making some documents that previously had no meaning have some minor meaning that may be wrong -- we're just moving documents from the category of "no meaning" to "wrong meaning"
  510. # [03:07] * Hixie goes back and looks at everything zeros wrote while he was saying that
  511. # [03:08] <Hixie> i don't see what you describe as a problem, no
  512. # [03:08] * Joins: wcox (chatzilla@70.101.178.102)
  513. # [03:09] <Zeros> I do.
  514. # [03:09] * Joins: laplink (link@212.33.131.105)
  515. # [03:10] <Hixie> then we disagree :-)
  516. # [03:10] <Zeros> I assume you have research that shows making it impossible to tell a meaningful b from a regular b is okay too?
  517. # [03:10] <Zeros> Or anything that shows it's *not* a problem?
  518. # [03:10] <Hixie> you can't prove a negative, typically
  519. # [03:10] * Quits: dbaron (dbaron@63.245.220.242) (Ping timeout)
  520. # [03:11] <Zeros> We can prove it is a problem though, with the enumerated points, of which you've stated don't matter because you just don't think they do.
  521. # [03:11] <Zeros> You've dismissed the issues with telling a meaningful document from a non-sense document with "I don't care"
  522. # [03:11] <Philip`> How is it possible to solve the problem of telling a meaningful b from a regular b?
  523. # [03:12] <Philip`> (given that whatever markup is added, people will misuse it to varying extents)
  524. # [03:12] <Zeros> Philip`, That's true of everything though, I wasn't touching that aspect. From here we can see that any page that used b before, as a presentational element (of which it's currently defined) becomes non-sense.
  525. # [03:13] <Zeros> And a document that looks like HTML4 may also be HTML5 so we can't tell those apart.
  526. # [03:13] <Hixie> Zeros: if we were talking about the difference between a link and a script insertion, then maybe it would be clearer that it's a problem. but we're talking about the difference between "text in a small font" and "small print", and "italic text" and "text that is offset from the other text", and "bold text" from "text that is highlighted", and i really don't see that that is an incompatible change
  527. # [03:14] <Hixie> Zeros: the difference is so small as to be academic, imho
  528. # [03:14] <Hixie> Zeros: can you give an example of where a user agent would process <i>-italics differently from <i>-offset-from-text?
  529. # [03:14] <Zeros> Hixie, One that has to read it out loud?
  530. # [03:15] <Zeros> Or one processing it for meaning
  531. # [03:15] <Zeros> <i> is used for presentation all over (as you already noted)
  532. # [03:15] <Hixie> Zeros: can you give an actual example? e.g. take emacsspeak, or jaws: what would they do with <i>-italics, and what would they do with <i>-offset-from-text that is different?
  533. # [03:15] <Zeros> "Hey look at my awesome page, every paragraph is in italics!"
  534. # [03:15] <Philip`> I think I may have meant to say, how is possible to tell a meaningful anything from a non-meaningful anything? It seems quite possible that that's impossible - and if you can never tell them apart, it's not an interesting problem to consider for a single specific feature that you still can't tell them apart because that's inevitable
  535. # [03:16] <Zeros> Hixie, I'm not sure they actual care about either in a lot of cases since they're unreliable
  536. # [03:16] <Philip`> (Er, that sentence didn't really make sense, I think)
  537. # [03:16] <Hixie> Philip`: that's one thing i mentioned in my long monologue earlier -- we have this problem anyway with e.g. <blockquote>
  538. # [03:16] <Hixie> Zeros: EXACTLY
  539. # [03:16] <Hixie> Zeros: so what's the problem?
  540. # [03:17] <Zeros> Hixie, And adding meaning to them means that screen readers CANNOT ever read them, since they will ALWAYS suffer from the old content on the web which used it for presentation.
  541. # [03:17] <Hixie> Zeros: in practice, they'll speak <i> slightly differently, whether the author used it to mean "italics" or whether the author used it to mean "offset-from-text"
  542. # [03:17] <Hixie> Zeros: in what way would the want to use <i> if there was no presentational legacy?
  543. # [03:17] <Hixie> s/the/they/
  544. # [03:17] <Zeros> Philip`, If you really wanted to get hot on the trail of meaning you'd have to remove all default presentation. If <foo> didn't change the way things looked, and just added meaning, it'd be abused less.
  545. # [03:18] <Zeros> Problematic for visual UAs though.
  546. # [03:19] <Zeros> Hixie, You mean why use them since they don't fall back on a presentational aspect?
  547. # [03:19] <Zeros> So we could define <center> to be the same as <section> then?
  548. # [03:20] <Hixie> Zeros: i mean if we introduced an element to mean "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, or a ship name", which wasn't <i>, how would the UA handle that element? how would it be _different_ from <i>?
  549. # [03:20] <Zeros> Hixie, How is <aside> different from <div>?
  550. # [03:20] <Zeros> It's the same argument.
  551. # [03:21] <Hixie> um
  552. # [03:21] <Hixie> no?
  553. # [03:21] <Zeros> How are they different, what will a UA do differently to it?
  554. # [03:21] <Hixie> aside allows authors to easily style a sidebar
  555. # [03:21] <Zeros> that's not the same argument, you're way off in left field.
  556. # [03:22] <Hixie> also <aside> gets involved in the algorithm for working out sections for tables of contents
  557. # [03:22] <Zeros> <mood> lets authors style that differently than italic presentational text.
  558. # [03:22] <Zeros> Same idea
  559. # [03:22] <Hixie> no, because we'd drop <i> if we introduced <mood>
  560. # [03:22] <Hixie> since we are getting rid of meaningless elements
  561. # [03:23] <Hixie> you still haven't answered my question :-)
  562. # [03:24] <Zeros> Assuming you didn't get rid of <i>, one in the UA could be used to form a dialog outline and chronicle moods.
  563. # [03:24] <Zeros> anyway, you don't really care. It's all wasted breathe here. I've suggested <email>, <copyright> and quite a few other elements and they all have use cases which are "not good enough"
  564. # [03:25] <Hixie> i myself have suggested dozens of elements and attributes that didn't make the cut
  565. # [03:25] <Hixie> don't take it personally
  566. # [03:25] <Zeros> I think I get why the WHATWG list is so much quieter than the html-wg one too. I'm sure in time that point will come as well.
  567. # [03:25] <Hixie> it's hard to make good suggestions for new elements at this stage, afterall we've been doing this for over 3 years now, most of the obvious ideas have already been considered
  568. # [03:26] * Quits: wcox (chatzilla@70.101.178.102) (Client exited)
  569. # [03:26] <Zeros> So why was summary removed from table?
  570. # [03:27] <Hixie> nobody uses it
  571. # [03:27] <Zeros> http://www.safercars.gov/ bingo
  572. # [03:27] <Hixie> (to be precise, it wasn't "removed", it was just not included. html5 was a blank slate into which html4 elements were added.)
  573. # [03:27] <Zeros> Their title is funny too
  574. # [03:28] <Hixie> that page is a perfect example of why summary="" sucks
  575. # [03:28] <Zeros> What did you research on summary show?
  576. # [03:28] <Zeros> your*
  577. # [03:28] <Hixie> the very first row says exactly what the summary says
  578. # [03:28] <Hixie> and since it's not tabular data, it shouldn't be a table in the first place
  579. # [03:28] <Hixie> let's see
  580. # [03:28] <Zeros> You said it wasn't used, not that it was duplicating the first line.
  581. # [03:29] <Hixie> sorry, i was counting bad uses as non-uses
  582. # [03:29] <Hixie> let me rephrase
  583. # [03:29] <Hixie> "it's never used correctly"
  584. # [03:29] <Zeros> prove it :)
  585. # [03:29] <Zeros> Or at least, show me your 'results' from research :p
  586. # [03:29] <Hixie> i can't, again, it's a negative :-)
  587. # [03:29] <Hixie> let's see
  588. # [03:29] * Joins: marcos (chatzilla@131.181.148.226)
  589. # [03:30] <Zeros> well show me that there were little or no cases used correctly in your results, we'll ignore fringe cases where google can't search it.
  590. # [03:30] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
  591. # [03:31] <Hixie> hm, i don't have the numbers on summary="" values here
  592. # [03:31] <Hixie> that might still be in my queue
  593. # [03:31] * Hixie searches
  594. # [03:31] <Zeros> http://diveintoaccessibility.org/day_20_providing_a_summary_for_tables.html
  595. # [03:31] <Zeros> There's two use cases for summary in that page
  596. # [03:31] <Hixie> ah, yeah, summary is in my list of "things i want to know that are going to be expensive to find out"
  597. # [03:32] <Hixie> oh don't get me wrong
  598. # [03:32] <Hixie> i think summary=, if it was used, would be useful for accessibility
  599. # [03:32] <Zeros> The other summary use cases are too
  600. # [03:32] <Zeros> JAWS reads it and so does iCab.
  601. # [03:32] <Hixie> but in practice most features that are only useful in "accessibility" contexts are abused or misunderstood
  602. # [03:33] * Joins: wcox (wcox@70.101.178.102)
  603. # [03:33] <Zeros> Well lets see then, compile a list of a lot of summaries and their attached pages, lets see how misused it is.
  604. # [03:33] <Zeros> I'm hoping google is capable of that
  605. # [03:33] <Hixie> yeah, that's going to have to be something we look at at some point
  606. # [03:33] <Zeros> I know the 508 people would have my head if I said we were going to remove summary.
  607. # [03:34] <Zeros> Speaking of which, did mjs ever propose his accessibility for media elements?
  608. # [03:34] <Hixie> the "508 people", in that case, care more about rules than about practicality
  609. # [03:34] <Hixie> what we SHOULD do is find a way to fix tables so they are accessible
  610. # [03:34] <Hixie> summary="", imho, is really not a good design
  611. # [03:35] <Zeros> For the people that need to use their 508 compliant pages their argument is perfectly valid
  612. # [03:35] <Zeros> And I'm betting there are lots of pages using it that google can't spider
  613. # [03:35] <Hixie> 508-compliance doesn't even remotely guarentee accessibility
  614. # [03:35] <Zeros> um, real compliancy does, yes.
  615. # [03:36] <Zeros> Some random "validator" doesn't
  616. # [03:36] <Hixie> e.g. the summary="" on the .gov page you listed above is a great example of summary="" actually hurting matters.
  617. # [03:36] <Zeros> Have you seen the 508 checklist that government employees need to go down?
  618. # [03:37] <Hixie> you mean http://www.section508.gov/index.cfm?FuseAction=Content&ID=14 ?
  619. # [03:37] <Hixie> or http://www.section508.gov/index.cfm?FuseAction=Content&ID=12 ?
  620. # [03:37] <Zeros> Yes
  621. # [03:38] <Zeros> And assuming you actually comply with all the points, you're making the page accessible.
  622. # [03:38] <Hixie> assuming you even understand what the points are saying
  623. # [03:38] <Hixie> you're already doing pretty well
  624. # [03:38] <Zeros> Get the check list, it makes it very clear.
  625. # [03:39] <Hixie> oh, you don't mean the above then
  626. # [03:39] <Hixie> i thought you did mean the above
  627. # [03:39] <Zeros> no
  628. # [03:39] <Hixie> you mean the actual checklist, like this one: http://www.webaim.org/standards/508/508checklist.pdf ?
  629. # [03:39] <Zeros> Yes, but it's the real one that they have in government offices.
  630. # [03:39] <Hixie> uri?
  631. # [03:40] <Zeros> I'm not sure of one, I have a printed copy somewhere, I'll have to find it for you.
  632. # [03:40] * Joins: inimino (inimino@75.71.88.233)
  633. # [03:40] <Zeros> It enumerates points very specifically "all video must have written transcripts or accessible closed captioning" etc.
  634. # [03:41] <Hixie> sure
  635. # [03:42] <Philip`> http://canvex.lazyilluminati.com/misc/summary.html - still statistically insignificant and biased but probably gives better than zero idea
  636. # [03:42] <Zeros> Philip`, where's that from?
  637. # [03:44] <Zeros> Hixie, http://www.cfug-md.org/meetings/VanessaHowles3Sec508Template1.doc
  638. # [03:44] <Hixie> well there's irony for you
  639. # [03:44] <Hixie> the accessibility document is inaccessible to me
  640. # [03:44] <Zeros> Oh?
  641. # [03:45] <Philip`> Zeros: From the combination of the top 1000 Yahoo search results for each of "the", "a" and "and"
  642. # [03:45] * Hixie jumps through hoops to get this word document to show something on his machine
  643. # [03:45] <Zeros> Philip`, You work for yahoo, or yahoo lets you scan markup?
  644. # [03:45] <Zeros> Hixie, What's wrong with the word doc?
  645. # [03:45] <Hixie> word's a proprietary format, i don't have good ways to read them
  646. # [03:46] <Philip`> Zeros: No, I just used their search API to get a list of those results, and then downloaded them and passed them through the html5lib parser
  647. # [03:46] <Hixie> Philip`: it's good data
  648. # [03:46] <Philip`> (hence only being ~2500 pages instead of billions)
  649. # [03:46] <Zeros> Hixie, It's not /that/ proprietary though, TextEdit.app, WordPad, OpenOffice?
  650. # [03:47] <Zeros> Certainly not as bad as Flash with the single player architecture, heh.
  651. # [03:47] <Philip`> (and being heavily biased towards front pages, and to English sites, and to whatever Yahoo thinks makes a site popular)
  652. # [03:47] <Zeros> Hixie, Want me to print to PDF for you?
  653. # [03:47] <Hixie> Zeros: is there a spec for it? the only tools i have that process it are ones that have reverse-engineered the format, and those are not ultrareliable
  654. # [03:47] <Hixie> no, i've got it up now
  655. # [03:47] <Hixie> Philip`: what would be interesting is the text in the attribute was in any way similar to the text at the start of the table
  656. # [03:47] <Zeros> You're in luck, Office XML gives you a spec Hixie (har har, it's useless too)
  657. # [03:48] <Zeros> If there every was a spec to come out of MS that was completely useless, that was it.
  658. # [03:48] <Hixie> calling the office xml spec a "spec" is an insult to my profession :-)
  659. # [03:48] <Zeros> The sarcasm in my statement should have been enough to kill small animals :)
  660. # [03:50] <Philip`> (Updated summary.html now to show the URLs it came from)
  661. # [03:51] <Zeros> Hixie, They're actually in the process of revising 508 now too
  662. # [03:53] <Zeros> Philip`, Some of those looks plenty valid. ridegear for one.
  663. # [03:54] <Hixie> theu ridegear.com site's tables are all presentational
  664. # [03:54] <Zeros> The number of "table is used for layout purposes" type ones is interesting
  665. # [03:55] <Hixie> yeah. talk about irony.
  666. # [03:55] * Quits: laplink (link@212.33.131.105) (Quit: This computer has gone to sleep)
  667. # [03:55] <Hixie> using an attribute intended to help accessibility to tell the user that the page isn't accessible
  668. # [03:55] <Zeros> Hixie, So what your objection to a transcript element inside media elements and source elements? (possibly an attribute)
  669. # [03:56] * Quits: marcos (chatzilla@131.181.148.226) (Ping timeout)
  670. # [03:57] <Philip`> I wonder if many of the summary="" are there because the table is irrelevant and should be skipped by non-visual readers, or because they just wanted to shut up the accessibility warnings without doing any work
  671. # [03:58] <Zeros> Hixie, Not for text content though, for pointing to a separate transcript like longdesc. Placing an entire transcript to a movie that's 20 minutes long right in the page can make the page very heavy.
  672. # [03:59] <Zeros> Use case is that 508 compliant pages must have a transcript, government sites right now add them separately with link below or inside the current media element.
  673. # [03:59] <Hixie> Zeros: dunno, haven't looked at the various proposals for <video> metadata stuff yet. there's a bunch of them on the pile.
  674. # [03:59] <Zeros> Screen readers could offer to load up the transcript as an option, browsers with flash disabled could offer to do it like an <iframe>
  675. # [03:59] <Zeros> ah
  676. # [04:00] <Hixie> as you say, it's something we need
  677. # [04:00] <Zeros> yes :)
  678. # [04:00] <Hixie> whether it should be an attribute (or something) on the video, or a rel="" value on <a>, or in-page content of some kind, is what we'll have to decide
  679. # [04:00] <Hixie> (or something else)
  680. # [04:00] <Zeros> ah yes
  681. # [04:01] <Zeros> rel feels problematic
  682. # [04:01] <Zeros> Is there a list of all the proposals somewhere?
  683. # [04:02] <Zeros> I'd be interested in forwarding it to the accessibility people I know working in government positions to see what their feedback was.
  684. # [04:02] <Hixie> yup, on my IMAP server :-)
  685. # [04:03] <Zeros> hah
  686. # [04:03] <Zeros> that's a little much effort for me to forward it ;)
  687. # [04:03] * Joins: marcos (chatzilla@131.181.148.226)
  688. # [04:05] <Zeros> Hixie, http://www.access-board.gov/ has information about the 508 and ADA committees
  689. # [04:08] <Zeros> All the 508 committee's presentation materials are available in two formats too, pdf or ppt and html or rtf for people who don't want to use a specless document
  690. # [04:09] * Quits: marcos (chatzilla@131.181.148.226) (Ping timeout)
  691. # [04:09] <Zeros> anyway, thanks for the discussion Hixie
  692. # [04:11] <Hixie> np
  693. # [04:16] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
  694. # [04:33] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  695. # [04:38] * Joins: gavin_ (gavin@74.103.208.221)
  696. # [04:51] * Joins: marcos (chatzilla@131.181.148.226)
  697. # [05:08] * Joins: mjs (mjs@64.81.48.145)
  698. # [05:50] * Quits: jdandrea (jdandrea@68.192.161.254) (Quit: jdandrea)
  699. # [05:55] * Quits: wcox (wcox@70.101.178.102) (Quit: wcox)
  700. # [06:00] * Joins: hyatt (hyatt@24.6.91.161)
  701. # [06:01] * Quits: hyatt (hyatt@24.6.91.161) (Client exited)
  702. # [06:01] * Joins: hyatt (hyatt@24.6.91.161)
  703. # [06:39] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  704. # [06:44] * Joins: gavin_ (gavin@74.103.208.221)
  705. # [06:48] * Quits: heycam (cam@203.214.12.71) (Ping timeout)
  706. # [06:51] * Joins: schepers (schepers@72.29.239.177)
  707. # [07:04] * Joins: heycam (cam@210.84.3.81)
  708. # [07:05] * Quits: schepers (schepers@72.29.239.177) (Quit: Free at last!)
  709. # [07:28] * Joins: myakura (myakura@125.194.247.196)
  710. # [07:36] * Joins: Zeros (Zeros-Elip@69.140.48.129)
  711. # [07:44] * Joins: dbaron (dbaron@71.198.189.81)
  712. # [07:57] * hyatt wonders if he has a cvs account now
  713. # [08:04] <cying> you probably do
  714. # [08:05] <cying> cp -rf WebKit/* Amaya/*
  715. # [08:05] <cying> cvs commit
  716. # [08:07] <cying> hyatt: i know i know, not funny...
  717. # [08:09] <Zeros> Are they still actively developing amaya?
  718. # [08:09] <hyatt> what's amaya, is that the w3c browser thingie
  719. # [08:10] <cying> yes
  720. # [08:11] <cying> i was having a discussion today with someone about how W3C could improve
  721. # [08:11] <cying> and i thought maybe if they backed implementation on a WebKit fork, that might be worthwhile
  722. # [08:12] <cying> get some real tests in there
  723. # [08:12] <cying> (in the specs, not in webkit)
  724. # [08:12] <cying> fantasy != reality
  725. # [08:22] <Zeros> amaya historically was awful
  726. # [08:24] <sbuluf> http://lists.w3.org/Archives/Public/www-tag/2006Nov/0077.html
  727. # [08:26] <Zeros> dead then I take it
  728. # [08:27] <Zeros> Whatever Amaya could/should have accomplished hopefully HTML5 can do so with test cases.
  729. # [08:29] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  730. # [08:34] * Joins: gavin_ (gavin@74.103.208.221)
  731. # [08:37] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  732. # [08:37] <hyatt> why webkit
  733. # [08:38] * Quits: marcos (chatzilla@131.181.148.226) (Ping timeout)
  734. # [08:39] * Joins: marcos (chatzilla@131.181.148.226)
  735. # [08:39] <Zeros> hyatt, because it's awesome?
  736. # [08:39] <hyatt> :)
  737. # [08:39] <hyatt> awwww
  738. # [08:39] <hyatt> flattery will get you everywhere
  739. # [08:39] <Zeros> sweet
  740. # [08:39] <Zeros> :)
  741. # [08:40] <Zeros> I found a weird bug the other day, I need to find that page again. Searching for a word actually got you into the middle of the result set. So previous would find earlier matches.
  742. # [08:42] * Joins: gavin_ (gavin@74.103.208.221)
  743. # [08:43] <Zeros> oh I know what it was, hmm, I bet that was my bad, nevermind.
  744. # [08:56] * Quits: inimino (inimino@75.71.88.233) (Ping timeout)
  745. # [08:56] * Joins: tH (r@87.102.22.235)
  746. # [08:58] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Quit: Leaving)
  747. # [09:04] * Joins: laplink (link@212.33.131.105)
  748. # [09:04] * Quits: laplink (link@212.33.131.105) (Quit: This computer has gone to sleep)
  749. # [09:05] * Joins: laplink (link@212.33.131.105)
  750. # [09:08] * Joins: loic (loic@86.71.4.162)
  751. # [09:45] * Quits: dbaron (dbaron@71.198.189.81) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  752. # [09:47] * Quits: myakura (myakura@125.194.247.196) (Ping timeout)
  753. # [10:00] * Quits: laplink (link@212.33.131.105) (Quit: Leaving)
  754. # [10:06] * Joins: zdenko (zdenko@193.77.152.244)
  755. # [10:23] * Joins: zcorpan_ (zcorpan@84.216.41.94)
  756. # [10:31] * Joins: ROBOd (robod@86.34.246.154)
  757. # [10:44] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  758. # [10:49] * Joins: gavin_ (gavin@74.103.208.221)
  759. # [10:55] * Quits: zcorpan_ (zcorpan@84.216.41.94) (Ping timeout)
  760. # [11:09] * Quits: sbuluf (rx@200.49.140.40) (Ping timeout)
  761. # [11:12] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
  762. # [11:13] * Joins: hyatt (hyatt@24.6.91.161)
  763. # [11:42] * Joins: zcorpan_ (zcorpan@84.216.41.94)
  764. # [12:01] * Joins: jdandrea (jdandrea@68.192.161.254)
  765. # [12:33] * Quits: gsnedders (gsnedders@86.139.123.225) (Quit: Don't touch /dev/null…)
  766. # [12:42] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
  767. # [12:45] <zcorpan_> is Henrik Leid smoking crack?
  768. # [12:45] <zcorpan_> s/Leid/Lied/
  769. # [12:45] <anne> you could ask
  770. # [12:46] <anne> if he is you might not get a meaningfull answer though :p
  771. # [12:46] <zcorpan_> heh
  772. # [12:51] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  773. # [12:56] * Joins: gavin_ (gavin@74.103.208.221)
  774. # [13:11] * Joins: myakura (myakura@125.194.247.196)
  775. # [13:47] * Joins: ddailey (david_dail@24.144.172.117)
  776. # [13:47] * Parts: ddailey (david_dail@24.144.172.117)
  777. # [13:48] * Joins: gsnedders (gsnedders@86.139.123.225)
  778. # [14:09] <hsivonen> oh. he'd like to kick anyone who suggests <indent>? I wonder if he'd like to do that because it is presentational or because it isn't compatible with legacy UAs that require <blockquote>.
  779. # [14:10] * Quits: zcorpan_ (zcorpan@84.216.41.94) (Ping timeout)
  780. # [14:30] <Lachy> Henrik seems to be reading too much into the meaning of "(public) Invited expert". It really just means contributor
  781. # [14:33] <Philip`> It seems to be a meaningless phrase that's only kept because otherwise it would require changing the Process which takes forever
  782. # [15:05] * Joins: zcorpan_ (zcorpan@130.243.79.10)
  783. # [15:06] <nickshanks> maybe we could change it to "Uninvited Idiot" :-)
  784. # [15:06] <anne> "One <burger/> please"
  785. # [15:07] <anne> (from DanC)
  786. # [15:07] <nickshanks> or, more seriously, "Interested Party"
  787. # [15:08] <Philip`> or "mailing list subscriber"
  788. # [15:09] <zcorpan_> "just another moron"
  789. # [15:11] <zcorpan_> or "self-invited nobody"
  790. # [15:12] * anne is glad to be part of a W3C Member
  791. # [15:12] * zcorpan_ doesn't care
  792. # [15:13] * Bob_le_Pointu is not.
  793. # [15:24] * Joins: briansuda (briansuda@82.221.34.106)
  794. # [15:25] * gsnedders attempts to not make a comment about anne not wanting a burger
  795. # [15:25] * gsnedders fails by saying taht
  796. # [15:25] <gsnedders> *that
  797. # [15:27] <nickshanks> i don't think <burger/> is semantic enough
  798. # [15:27] * Joins: zcorpan (zcorpan@84.216.40.21)
  799. # [15:28] <anne> it doesn't have to be
  800. # [15:28] <anne> it's quite temporary
  801. # [15:28] <nickshanks> it doesn't have to be, as long as it's a WYSIWYG burger chain?
  802. # [15:29] <anne> it's eaten during parsing
  803. # [15:29] <gsnedders> not tokenising?
  804. # [15:29] <anne> neh
  805. # [15:29] <anne> that would be hard
  806. # [15:29] <gsnedders> because otherwise isn't it left open?
  807. # [15:29] <anne> you first have to make the token to eat it :)
  808. # [15:29] <gsnedders> :)
  809. # [15:29] * Quits: zcorpan_ (zcorpan@130.243.79.10) (Ping timeout)
  810. # [15:30] * Joins: zcorpan_ (zcorpan@84.216.40.21)
  811. # [15:30] <Philip`> It fits in nicely with the existing elements - <menu><burger/><option value="$1.99">Large</option><option value="$3.99">Extra Large</option></menu>
  812. # [15:31] <anne> <input type="<burger/>">
  813. # [15:32] * Quits: zcorpan (zcorpan@84.216.40.21) (Ping timeout)
  814. # [15:32] <gsnedders> but that creates parser errors!111!!!111onee1!!eleventy!!!
  815. # [15:32] <anne> no it doesn't
  816. # [15:32] <gsnedders> < doesn't create a parser error any more? oh.
  817. # [15:33] <Philip`> <input type="mouth" required="<burger/>">
  818. # [15:34] <anne> gsnedders, it never did
  819. # [15:34] <anne> gsnedders, inside double or single quoted attribute values in HTML5, that is
  820. # [15:34] <gsnedders> anne: it does in XML
  821. # [15:34] <anne> who cares about that?
  822. # [15:34] <anne> (my XML5 prototype allows them fwiw)
  823. # [15:34] <gsnedders> anne: and it does in SGML. I can't remember HTML5's tokeniser's details so well :P
  824. # [15:35] <Philip`> This <burger/> looks like XML
  825. # [15:35] <gsnedders> anne: I just assumed anywhere where there was a parse error in SGML there was one in HTML5
  826. # [15:35] <zcorpan_> gsnedders: < in a quoted attribute value is allowed in sgml iirc
  827. # [15:35] * Quits: briansuda (briansuda@82.221.34.106) (Quit: briansuda)
  828. # [15:36] * gsnedders doesn't have access to a copy of the SGML spec here to check, but he thinks otherwise
  829. # [15:36] <anne> Philip`, it's a void tag with a symbol of faith to please the XML gods
  830. # [15:38] <zcorpan_> gsnedders: in any case, parse errors in sgml doesn't imply parse errors in html5... e.g. <foo bar> is a parse error in sgml unless "bar" is a value defined in the dtd. not a parser error in html5
  831. # [15:39] <gsnedders> zcorpan_: well sure, seeming HTML5 doesn't have DTDs
  832. # [15:42] * Joins: briansuda (briansuda@82.221.34.106)
  833. # [16:10] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  834. # [16:13] * Joins: Shunsuke (Shunsuke@219.110.80.235)
  835. # [16:15] * Joins: gavin_ (gavin@74.103.208.221)
  836. # [16:34] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Ping timeout)
  837. # [16:36] * Joins: billmason (billmason@69.30.57.156)
  838. # [16:44] * Joins: AnPol (anpol@85.118.224.254)
  839. # [16:51] * Joins: DanC_lap (connolly@128.30.52.30)
  840. # [16:52] * Quits: zdenko (zdenko@193.77.152.244) (Quit: zdenko)
  841. # [16:52] * Quits: briansuda (briansuda@82.221.34.106) (Quit: briansuda)
  842. # [16:55] * Joins: h3h (bfults@66.162.32.234)
  843. # [17:02] * Joins: Shunsuke (Shunsuke@219.110.80.235)
  844. # [17:16] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
  845. # [17:29] * Joins: foca (foca@190.64.207.115)
  846. # [17:32] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
  847. # [17:33] * Joins: DanC_lap (connolly@128.30.52.30)
  848. # [17:38] * Parts: foca (foca@190.64.207.115)
  849. # [17:46] * Quits: AnPol (anpol@85.118.224.254) (Quit: Bye)
  850. # [17:49] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Ping timeout)
  851. # [17:49] * Joins: Shunsuke (Shunsuke@219.110.80.235)
  852. # [17:52] * Joins: schepers (schepers@72.29.239.177)
  853. # [17:55] * Quits: tH (r@87.102.22.235) (Ping timeout)
  854. # [17:59] * Joins: tH (r@87.102.22.235)
  855. # [18:02] <cying> i have a stupid question
  856. # [18:02] <cying> RELAXNG, DTD, schemas,... they all serve to declaratively specify a grammar for a particular language...
  857. # [18:03] <cying> couldn't they be replaced with a procedural imperative language?
  858. # [18:03] <cying> since, correct me if i'm wrong, things like SVG, HTML5 and CSS can't be validated simply with a DTD.
  859. # [18:04] <hsivonen> cying: replaced for what purpose?
  860. # [18:05] * Quits: schepers (schepers@72.29.239.177) (Quit: Free at last!)
  861. # [18:05] <cying> hsivonen: so that something like the internals of SVG's d attribute could be well-specified by something other than paragraphs of text
  862. # [18:05] <hsivonen> cying: if for validation, the answer is "yes"
  863. # [18:05] <cying> hsivonen: ohhh, i forgot about BNF
  864. # [18:05] <cying> hsivonen: i guess i'm looking for something more meaningful than BNF
  865. # [18:05] <cying> grammars
  866. # [18:06] <hsivonen> cying: what you are looking for is Python or Java
  867. # [18:06] <cying> ECMA claims to be using ML for ECMAScript 4 or 5
  868. # [18:06] <cying> hsivonen: yes, i wonder if the html5lib could be it
  869. # [18:06] <hsivonen> cying: html5lib is just a parser
  870. # [18:06] <cying> hsivonen: but i guess i thought it would be fun as part of a formal spec
  871. # [18:07] <cying> that's true
  872. # [18:07] <cying> but perhaps a validator + test suite for the validator could be a formal effort by the WG
  873. # [18:08] <cying> in Python, perhaps
  874. # [18:11] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
  875. # [18:11] * Joins: kazuhito (kazuhito@222.151.148.23)
  876. # [18:12] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  877. # [18:12] <hsivonen> cying: are you aware that there already is a non-vaporware project?
  878. # [18:12] <cying> hsivonen: no, what's it called?
  879. # [18:13] <hsivonen> http://hsivonen.iki.fi/validator/html5/
  880. # [18:13] <hsivonen> documentation: http://hsivonen.iki.fi/thesis/
  881. # [18:14] <cying> cool
  882. # [18:15] <cying> is it schema validation only or do you intend to check attribute syntax?
  883. # [18:16] <hsivonen> cying: it is not validation only and I already check attribute syntax (but incompletely at this point)
  884. # [18:16] <cying> <path d="M35,20 L23,35 ...." transform="scale(30, 40) rotate(10, 20) ..." />
  885. # [18:16] <hsivonen> SVG is on my todo list after HTML5
  886. # [18:18] <cying> fascinating, well this is a great effort
  887. # [18:18] <cying> it's too bad it's in java though
  888. # [18:18] <cying> for me, it'll be harder to contribute
  889. # [18:19] <cying> but i suppose, given the broad range of tools used to validate W3C specs it may be the right choice for its intended use
  890. # [18:19] <hsivonen> cying: of garbage collected languages that run on various Unix-like systems Java has the best XML library ecosystem
  891. # [18:19] <cying> right
  892. # [18:20] <hsivonen> Python was the runner-up that didn't get chosen
  893. # [18:20] <cying> i wonder if a HTML5 only one in Python could be written
  894. # [18:20] <cying> that was shorter and easier for spec contributors to edit
  895. # [18:21] <cying> anyway, more vaporware talk,
  896. # [18:21] * MikeSmith thinks cying should take some time to read hsivonen's thesis
  897. # [18:22] <hsivonen> cying: you do realize that my implementation is based on a RELAX NG schema for the most part and RELAX NG Compact Syntax is easier to edit than Python?
  898. # [18:22] <hsivonen> part of the point of choosing Java is that Java has a RELAX NG validator written by one of the editors of the RELAX NG spec
  899. # [18:23] <hsivonen> the other reason is that SAX is ubiquitous in the Java world, so all libraries fit together
  900. # [18:29] <nickshanks> whenever i see that i think of frankie goes to hollywood
  901. # [18:30] <nickshanks> and the 'ng!' bit just adds to the aural imagery …
  902. # [18:39] <cying> hmmm
  903. # [18:39] <cying> i think i will do some more research
  904. # [18:39] <cying> i thought that RELAX NG was only opaque outside of attributes
  905. # [18:39] <cying> but i wonder what it does with HTML tag soup
  906. # [18:39] <cying> so i will go and read up more on RELAX NG
  907. # [18:40] <cying> hsivonen: very cool stuff
  908. # [18:41] <hsivonen> cying: RELAX NG validators can use libraries implemented in Turing-complete languages to check the inside of attributes
  909. # [18:41] <cying> hsivonen: ah
  910. # [18:41] <hsivonen> cying: again, the API situation is the best for Java
  911. # [18:42] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
  912. # [18:42] <cying> hsivonen: i don't doubt it
  913. # [18:44] * Joins: DanC_lap (connolly@128.30.52.30)
  914. # [18:49] * Quits: cying (cying@75.18.223.137) (Quit: cying)
  915. # [19:03] * Joins: olivier (ot@128.30.52.30)
  916. # [19:05] * Joins: Sander (svl@71.57.109.108)
  917. # [19:11] * Joins: mjs (mjs@17.255.105.149)
  918. # [19:17] * Joins: schepers (schepers@72.29.239.177)
  919. # [19:21] * Quits: tH (r@87.102.22.235) (Ping timeout)
  920. # [19:22] * Quits: Sander (svl@71.57.109.108) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  921. # [19:24] * Joins: Sander (svl@71.57.109.108)
  922. # [19:25] * Joins: tH (r@87.102.22.235)
  923. # [19:39] * Quits: tH (r@87.102.22.235) (Ping timeout)
  924. # [19:41] * Joins: tH (r@87.102.22.235)
  925. # [19:47] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Quit: See you...)
  926. # [19:55] * Joins: dbaron (dbaron@63.245.220.242)
  927. # [19:55] * Joins: Shunsuke (Shunsuke@219.110.80.235)
  928. # [19:58] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Quit: See you...)
  929. # [20:01] * Quits: tH (r@87.102.22.235) (Ping timeout)
  930. # [20:02] * Joins: tH (r@87.102.22.235)
  931. # [20:07] * Quits: schepers (schepers@72.29.239.177) (Quit: Free at last!)
  932. # [20:12] <zcorpan_> perhaps PaveTheCowpaths should be more clear that it's not intended to adopt *anything* that is wide-spread, just don't forbid harmless things
  933. # [20:12] <zcorpan_> apparently some people think it means the former
  934. # [20:12] * Quits: olivier (ot@128.30.52.30) (Quit: This computer has gone to sleep)
  935. # [20:15] <Philip`> It already says "consider adopting it" which sounds distinct enough from 'always adopt it' and still allows room for thinking
  936. # [20:16] <Lachy> yeah, we need to do some serious PR work this week to address the misunderstandings and fears people have about such things
  937. # [20:16] <Hixie> are we allowed to talk here?
  938. # [20:16] <Philip`> (Incidentally, http://www.archive.org/details/whiffsfromwildme00fossiala has the original copy of the poem - it seems to have been mutated quite a bit in its journey around the web, at least in terms of formatting)
  939. # [20:16] <zcorpan_> yup, just not on the mailing list (i think) :)
  940. # [20:24] * Quits: myakura (myakura@125.194.247.196) (Ping timeout)
  941. # [20:24] <mjs> zcorpan_: it was really meant to be more about practices that are orthogonal to existing standards rather than contrary ones, although there is a bit of each
  942. # [20:35] * Joins: Zeros (Zeros-Elip@67.154.87.254)
  943. # [20:39] * Quits: kazuhito (kazuhito@222.151.148.23) (Quit: Computer goes to sleep!)
  944. # [20:40] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
  945. # [20:43] <zcorpan_> mjs: yeah, i'm just noticing that some of them are causing FUD
  946. # [20:45] <zcorpan_> s/them/the proposed design principles/
  947. # [20:45] <Hixie> Pave The Cowpaths really should be about paving the cowpaths when something is paved at all -- i.e. given a requirement, satisfy it by enshrining what authors do instead of inventing something new that they have to learn.
  948. # [20:46] <Hixie> or maybe it should be about adding features based on what authors do, rather than on what we think they do
  949. # [20:47] <Hixie> basically, it's either "class="footer" is used, so we should enshrine it" or "class="footer" is used, so we should have <footer>"
  950. # [20:47] <Lachy> <footer> is the safer alternative, given the recent debate about predefined classes
  951. # [20:49] <mjs> zcorpan_: I'm certainly happy to clarify it (and I owe a rewrite of Support Existing Content), but DanC asked me not to talk about it
  952. # [20:49] <mjs> (on the mailing list)
  953. # [20:49] <Hixie> Lachy: right, my point was that i'm not sure which one is intended
  954. # [20:49] <mjs> he also put the design principles on indefinite hold, even though both designated reviewers came back with a mostly positive evaluation
  955. # [20:50] <mjs> Hixie: it's meant to be the former (and at "consider" level, so could be outweighed by other technical issues), but we should also have something about the latter
  956. # [20:50] * Joins: hasather (hasather@81.235.209.174)
  957. # [20:51] <Hixie> mjs: would be interesting to have more examples from the spec than just <br/>
  958. # [20:51] <mjs> Hixie: predefined classes would be an example, though likely a controversial one
  959. # [20:51] <Hixie> yeah
  960. # [20:52] <Hixie> predefined classes are an argument against this principle
  961. # [20:53] <mjs> well, they are subject to your "given a requirement" proviso
  962. # [20:53] <mjs> I'm not sure what requirement, if any, the current predefined classes satisfy
  963. # [20:54] <Hixie> true
  964. # [20:54] * Joins: DanC_lap (connolly@128.30.52.30)
  965. # [20:54] <Hixie> i really think i'm gonna yank it
  966. # [20:54] <Hixie> the only thing i actually cared about was class=copyright, and we can deal with that use case with <small>
  967. # [20:54] <Hixie> oh! <small> is a pave-the-cowpaths
  968. # [20:54] <mjs> good point
  969. # [20:54] <Hixie> duh
  970. # [20:54] <Hixie> shoulda thought of that
  971. # [20:54] <Hixie> wait, i did
  972. # [20:54] <Hixie> nevermind
  973. # [20:54] <Hixie> moving right along
  974. # [20:55] <Hixie> so yeah. the other classes in the spec now are handled by <aside>, mostly
  975. # [20:55] <Hixie> and i think that's all _i_ need from the point of view of writing the spec
  976. # [20:55] <Hixie> (e.g. making examples and notes <aside>s)
  977. # [20:55] <mjs> I like <small> better than class="copyright", as it is more general and the actual copyright notice can be identified through trivial textual analysis so class="copyright" doesn't help much
  978. # [20:55] <Hixie> yeah
  979. # [20:55] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  980. # [20:56] <Hixie> class="copyright" as far as i can tell is just used for making small fonts, too
  981. # [21:00] * Joins: gavin_ (gavin@74.103.208.221)
  982. # [21:01] <nickshanks> making fonts small, not making small fonts ;)
  983. # [21:06] <hsivonen> hmm. XHTML 1.0 2nd ed. has been translated into a larger number of languages than HTML 4.01 that in included by reference :-)
  984. # [21:08] <nickshanks> does that include be-x-old ?
  985. # [21:09] <nickshanks> which apparently has 7000 wikipedia articles: http://be-x-old.wikipedia.org/
  986. # [21:11] <hsivonen> what does Breton have to do with the Cyrillic script??
  987. # [21:12] <hsivonen> hmm. the list I'm looking at has the same 2-letter code for Byelorussian and Breton
  988. # [21:13] * Joins: olivier (ot@128.30.52.30)
  989. # [21:14] <hsivonen> IANA spells it Belarusian
  990. # [21:15] <hsivonen> and Apple's dictionary Belorussian
  991. # [21:18] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
  992. # [21:54] * Quits: loic (loic@86.71.4.162) (Quit: hoopa rules)
  993. # [21:54] * Joins: edas (edaspet@88.191.34.123)
  994. # [21:59] * Quits: edas (edaspet@88.191.34.123) (Quit: http://eric.daspet.name/ et l'édition 2007 de http://www.paris-web.fr/ )
  995. # [22:01] * Quits: hasather (hasather@81.235.209.174) (Client exited)
  996. # [22:02] * Joins: hasather (hasather@81.235.209.174)
  997. # [22:02] * Joins: myakura (myakura@125.194.247.196)
  998. # [22:02] * Joins: DanC_lap (connolly@128.30.52.30)
  999. # [22:08] * Joins: Bony_M (elare@213.7.67.30)
  1000. # [22:10] <Bony_M> Hello. <marguee> can be used in html and xhtml ?
  1001. # [22:12] <Bony_M> Hello. <marguee> can be used in html and xhtml ?
  1002. # [22:12] <Zeros> Provided the browser implemented it, since it's not part of the standard. I think most of them did, though a little differently in each IIRC.
  1003. # [22:13] <Bony_M> ok thanks
  1004. # [22:13] * Quits: Bony_M (elare@213.7.67.30) (Quit: Bony_M)
  1005. # [22:13] <Zeros> :/
  1006. # [22:14] <gavin> I think he took that as a "yes" :)
  1007. # [22:15] <Philip`> It's technically true that marquee can be used, and it will work - he didn't ask if it actually should be used :-)
  1008. # [22:16] <Philip`> ...although he'd have to spell it correctly first, since HTML's error handling doesn't go that far
  1009. # [22:16] <mjs> it depends on what you mean by "can"
  1010. # [22:18] <gavin> also what you mean by "html" and "xhtml"
  1011. # [22:19] <Zeros> I can only imagine if browsers used a shortest unambiguous tag name error correction system like WPS...
  1012. # [22:20] <Philip`> Why limit it to unambiguous cases? Just choose the tag with the minimal Hamming distance from what the author typed in
  1013. # [22:22] <Philip`> As long as it's well-defined, it'd allow new possibilities for extensibility - you could add new tags that get error-corrected into <div> or <span> or <blockquote> or whatever so that you get the right effect in old browsers, just by choosing the new element name sufficiently carefully
  1014. # [22:22] <Zeros> Sure, that opens the door to all kinds of fun
  1015. # [22:24] <Zeros> Then we really could have a <dog>
  1016. # [22:27] <gsnedders> Philip`: error handling has odd things in it — <image> == <img>
  1017. # [22:44] * Joins: zdenko (zdenko@84.255.203.169)
  1018. # [22:49] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
  1019. # [23:09] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
  1020. # [23:15] * Quits: olivier (ot@128.30.52.30) (Quit: This computer has gone to sleep)
  1021. # [23:22] * Joins: DanC_lap (connolly@128.30.52.30)
  1022. # [23:22] * Joins: olivier (ot@128.30.52.30)
  1023. # [23:27] * Joins: zdenko_ (zdenko@84.255.203.169)
  1024. # [23:27] * Quits: zdenko (zdenko@84.255.203.169) (Connection reset by peer)
  1025. # [23:37] * Joins: inimino (inimino@75.71.88.233)
  1026. # [23:51] * Joins: kingryan (rking3@142.131.37.98)
  1027. # [23:57] * Joins: timblair (timblair@87.74.129.183)
  1028. # Session Close: Sat May 12 00:00:00 2007

The end :)