/irc-logs / freenode / #whatwg / 2008-01-26 / end

Options:

  1. # Session Start: Sat Jan 26 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:00] <Hixie> i disagree with much of webarch
  4. # [00:00] <Hixie> i haven't recently checked whether i agree or disagree with that particular section, or whether it applies here.
  5. # [00:00] * Joins: othermaciej_ (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  6. # [00:00] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
  7. # [00:01] <annevk> i see
  8. # [00:01] <annevk> might not have been the smartest move :)
  9. # [00:05] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  10. # [00:06] * Quits: jruderman_ (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  11. # [00:10] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  12. # [00:15] * eseidel_ is now known as MacDome
  13. # [00:17] * Quits: Ketsuban (n=ketsuban@cpc2-oxfd8-0-0-cust335.oxfd.cable.ntl.com) ("Perhaps on the rare occasion pursuing the right course demands an act of piracy, piracy itself can be the right course?")
  14. # [00:18] * Joins: Ketsuban (n=ketsuban@cpc2-oxfd8-0-0-cust335.oxfd.cable.ntl.com)
  15. # [00:21] * Joins: eseidel_ (n=eseidel@72.14.224.1)
  16. # [00:22] * Joins: eseidel__ (n=eseidel@nat/google/x-0ca120597f3116c9)
  17. # [00:26] * Joins: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  18. # [00:31] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  19. # [00:31] * Quits: othermaciej_ (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
  20. # [00:31] * Quits: csarven (n=nevrasc@on-irc.csarven.ca) (Connection timed out)
  21. # [00:33] * Joins: othermaciej_ (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  22. # [00:33] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
  23. # [00:35] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  24. # [00:35] * jwalden wonders why HTML5 forbids UTF-32
  25. # [00:35] <gsnedders> jwalden: because it's pointless, it's verbose, and nobody uses it
  26. # [00:36] <gsnedders> jwalden: and it doesn't forbid it, it's just SHOULD NOT
  27. # [00:36] <jwalden> <https://bugzilla.mozilla.org/show_bug.cgi?id=414064#c0> claims it's a must not
  28. # [00:36] * Quits: MacDome (n=eseidel@nat/google/x-156f219b7d0865d3) (Read error: 110 (Connection timed out))
  29. # [00:36] <gsnedders> jwalden: then either the spec or the bug report is wrong :)
  30. # [00:36] <gsnedders> "Authors should not use UTF-32."
  31. # [00:36] <Dashiva> If you use enough non-BMP characters that UTF-32 is a size advantage, I'd like to see it :)
  32. # [00:37] <gsnedders> "Support for UTF-32 is not recommended."
  33. # [00:37] <Dashiva> jwalden: Um
  34. # [00:37] <gsnedders> jwalden: i..e, the bug report is wrong :)
  35. # [00:37] <jwalden> I can't speak to the third, the second's accurate, but the first seems wrong in that you have constant-time indexing access, which might be useful
  36. # [00:37] <gsnedders> jwalden: no, the bug report is right. it doesn't say UTF-32 is must not
  37. # [00:37] * Quits: eseidel_ (n=eseidel@72.14.224.1) (Read error: 110 (Connection timed out))
  38. # [00:37] <jwalden> er
  39. # [00:37] <gavin> that comment doesn't say that it's a MUST NOT
  40. # [00:38] <jwalden> oh, misread
  41. # [00:38] <annevk> not recommended == should not
  42. # [00:38] <jwalden> blah
  43. # [00:38] * Quits: blooberry (n=brian@c-76-126-109-10.hsd1.ca.comcast.net)
  44. # [00:38] <jwalden> I skimmed the first part and assumed UTF-32 was in the same category
  45. # [00:38] <jwalden> without reading the latter half of the paragraph closely
  46. # [00:38] * jwalden wonders how else he can waste everyone's time here!
  47. # [00:39] <gsnedders> jwalden: tell me to go to bed
  48. # [00:39] <Dashiva> jwalden: Watch me and learn
  49. # [00:39] * jwalden just learned!
  50. # [00:42] <annevk> i wouldn't mind must not i think
  51. # [00:43] <annevk> the less encodings the better
  52. # [00:43] <gsnedders> I don't see why it should be must not
  53. # [00:44] <gsnedders> it's so little code once you have unicode support anyway
  54. # [00:44] <annevk> oliver hunt in this channel?
  55. # [00:44] <annevk> less encodings, less edge case testing, less bugs, fewer options, etc.
  56. # [00:45] <jgraham> Authors must not use UTF-32, UAs should not support UTF-32
  57. # [00:45] * Quits: othermaciej_ (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
  58. # [00:45] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  59. # [00:49] <SadEagle> annevk: he is olliej on #webkit, I think
  60. # [00:50] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.2 (IRC client for Emacs)")
  61. # [00:52] * Quits: virtuelv (n=virtuelv@65.80-202-82.nextgentel.com) (Read error: 110 (Connection timed out))
  62. # [01:01] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
  63. # [01:01] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  64. # [01:15] * Quits: cgriego (n=cgriego@216.138.69.206)
  65. # [01:16] * Quits: eseidel__ (n=eseidel@nat/google/x-0ca120597f3116c9)
  66. # [01:20] * Joins: Philip`_ (n=philip@zaynar.demon.co.uk)
  67. # [01:24] * Quits: billmason (n=billmaso@ip129.unival.com) (Read error: 104 (Connection reset by peer))
  68. # [01:36] * Quits: Philip` (n=philip@zaynar.demon.co.uk) (Read error: 110 (Connection timed out))
  69. # [01:42] <annevk> http://pipwerks.com/journal/2008/01/25/html-5-the-strong-element/
  70. # [01:42] <annevk> SadEagle, thanks btw
  71. # [01:42] <SadEagle> np
  72. # [01:42] * Philip`_ is now known as Philip`
  73. # [01:43] * SadEagle thinks it'll be confusing for the default stylesheet
  74. # [01:43] <annevk> the default style sheet will be 'b, strong { font-weight:bolder }' presumably
  75. # [01:43] <annevk> or maybe for <b> it will just be 'b { font-weight:bold }'
  76. # [01:43] <annevk> hmm
  77. # [01:44] <annevk> it's not like browsers show much of a difference between the various font weights
  78. # [01:45] <SadEagle> Not too many fonts have natural variants for many weights --- or am I mistaken?
  79. # [01:46] <annevk> i guess that's the easy, yeah
  80. # [01:47] <SadEagle> this is kind of weird, since it seems like the styling one wants depends on appearance of the markup above, and not its element/etc. structure (or am I confusing myself?)
  81. # [01:48] <annevk> hmm, Safari doesn't support Link: <foobar.css>;rel=stylesheet
  82. # [01:49] <annevk> SadEagle, I'm not sure I understand what you're saying
  83. # [01:49] <annevk> as far as default styling goes, that's pretty much locked by legacy
  84. # [01:51] <SadEagle> annevk: I think I was being silly (I often am). the default styling of semantic elements isn't normally robust against changes to styling of surrounfing markup, right..
  85. # [01:52] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  86. # [02:09] * Quits: tndH (i=Rob@83.100.254.128) ("ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  87. # [02:17] * Quits: shepazu (n=schepers@cpe-069-134-123-228.nc.res.rr.com) ("Core Breach")
  88. # [02:31] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  89. # [02:32] <zcorpan_> // ok we have a conforming XHTML1 doc in |doc| now.
  90. # [02:32] <zcorpan_> not true, the root element doesn't contain an xmlns declaration as the spec requires ;)
  91. # [02:33] <zcorpan_> (acid3)
  92. # [02:35] * jwalden snickers
  93. # [02:35] <SadEagle> silly serializations and their xmlns attributes :-)
  94. # [02:36] <jwalden> silly DOM
  95. # [02:36] <jwalden> silly XML
  96. # [02:36] <SadEagle> DOM doesn't need xmlns's, though.
  97. # [02:36] <zcorpan_> silly xhtml spec that specifies document conformance in terms of the xml serialization
  98. # [02:37] <SadEagle> <chuckle>
  99. # [02:37] <Philip`> Is that an HTML-serialised chuckle, or are you just being ill formed?
  100. # [02:38] <SadEagle> no, that's IRC-serialization
  101. # [02:38] <Philip`> Hmm, that sounds highly unstandardised
  102. # [02:39] <SadEagle> thankfully, the typical parsers are highly robust
  103. # [02:40] * zcorpan_ is still waiting for the end tag before rendering
  104. # [02:40] <Philip`> They have the advantage of being able to ask the author for clarification in case of unresolvable parsing ambiguities
  105. # [02:41] * zcorpan_ doesn't support incremental content sink yet :(
  106. # [02:41] <Ketsuban> </chuckle>
  107. # [02:42] <zcorpan_> ah, thanks!
  108. # [02:42] <SadEagle> Philip`: the advantage is in a case? how odd
  109. # [02:49] <othermaciej> do xmlns attributes have to appear in the DOM?
  110. # [02:50] <othermaciej> (and do they affecte seriaization, if the element has the right namespace anyway?)
  111. # [02:50] <zcorpan_> othermaciej: not sure if they have to, but they do appear
  112. # [02:50] <SadEagle> I presume the second aprt would be DOM3 L&S, right?
  113. # [02:54] <othermaciej> DOM3 L&S is a pile of pernicious nonsense
  114. # [02:54] <othermaciej> but I guess something has to define it for specs like XHR and HTML5 to rely on
  115. # [02:55] <SadEagle> I guess for a usable serialization, it should produce xmlns attributes, but they can be local to each element that needs them...
  116. # [02:55] <zcorpan_> othermaciej: i guess declarations that are in conflict with the element's namespace or prefix is dropped or modified in the serialization, and unused declarations are serialized... well, assuming the serializer is sane
  117. # [02:55] <SadEagle> Ah prefixes... forgot that they're in the DOM.
  118. # [02:56] <SadEagle> So it's pretty easy to make a DOM that's not serializable to XML
  119. # [02:56] <othermaciej> zcorpan_: declarations could even be in conflict with children, if they were added through the DOM
  120. # [02:56] <zcorpan_> othermaciej: yeah, true
  121. # [02:56] <othermaciej> (I guess children could override them though
  122. # [02:56] <othermaciej> )
  123. # [02:56] <othermaciej> so yeah, you can still do something sane an element at a time
  124. # [02:57] <SadEagle> attr's have their own namespace, don't they?
  125. # [02:57] <zcorpan_> yes
  126. # [02:57] <zcorpan_> namespace declarations have are in a special namespace
  127. # [02:57] <othermaciej> the meme that IE8 bugmode was developed "in collaboration with the Web Standards Project" has impressive traction
  128. # [02:57] <othermaciej> mentioned on ars technical with no disclaimer: http://arstechnica.com/articles/paedia/ie8-super-standards-mode.ars
  129. # [02:58] <othermaciej> ok I have a debate topic
  130. # [02:58] <othermaciej> XML Namespaces: Useless or Pointless?
  131. # [02:58] <othermaciej> discuss
  132. # [02:58] <zcorpan_> at least wrongly designed
  133. # [02:58] <SadEagle> zcorpan_: then one can probably use the same prefix with different namespaceURIs for an element and its attributes.. I don't think that's serializable
  134. # [02:58] <SadEagle> othermaciej: I like the idea, not the implementation
  135. # [02:59] <othermaciej> the concept of namespaces in general is good
  136. # [02:59] <SadEagle> CSS gets it better, IMHO
  137. # [02:59] <othermaciej> Namespaces in XML has some major problems
  138. # [02:59] <zcorpan_> SadEagle: serializable if you modify the prefixes
  139. # [02:59] <othermaciej> 1) the fact that namespace unique identifiers are URIs (and typically long, unmemorable http URIs) --> stupid
  140. # [03:00] <othermaciej> 2) the use of attribute syntax
  141. # [03:00] <SadEagle> re: #1: that's the easy way of managing a namespace. re: #2: that's why I think CSS gets it better :-)
  142. # [03:00] <othermaciej> 3) the two level thing with namespace URIs and prefixes, resulting in non-local prefix definitions
  143. # [03:01] <othermaciej> SadEagle: just DNS domain names would be better than URIs, if it is a critical goal not to add a registry
  144. # [03:01] <othermaciej> however, DNS is also a registry
  145. # [03:01] <othermaciej> if namespace identifiers were something that could be used as a prefix directly, it would suck a lot less
  146. # [03:01] <SadEagle> I guess one can shorten them w/o losing much. e.g. w3c.org/xhtml1
  147. # [03:02] <othermaciej> if you could "import" namespaces like in C++ so long as they don't conflict, it would suck a lot less
  148. # [03:02] <SadEagle> that doesn't layer
  149. # [03:02] <othermaciej> "layer"?
  150. # [03:03] <othermaciej> I guess you'd still have to say something when creating elements
  151. # [03:03] <SadEagle> well, you can't make the parser resolve them. But that might not be such a big deal as on first sight
  152. # [03:03] <othermaciej> still, having only one kind of identifier which is always unique and if needed a registry for them would suck a lot less
  153. # [03:03] <othermaciej> but even org.w3c.xhtml (a la Java) would be way better than http://www.w3.org/1999/xhtm
  154. # [03:04] <othermaciej> (er, sorry, lost the l)
  155. # [03:04] <zcorpan_> a bit annoying if you want to use it as prefix for all elements though
  156. # [03:05] <othermaciej> this would also solve the problem that namespace-prefixed keywords in attribute values create
  157. # [03:05] <SadEagle> I'd personally have namespaceless attributes.
  158. # [03:05] <SadEagle> since their interpretation depends on the element, anyway.
  159. # [03:06] <zcorpan_> speaking of that
  160. # [03:06] <SadEagle> I guess it might help in cases like WF2, though.
  161. # [03:06] <zcorpan_> i think the xml: attributes suck
  162. # [03:06] <othermaciej> in theory namespaced attributes are intended to be element-independent
  163. # [03:06] <othermaciej> xml:id certainly sucks
  164. # [03:07] <zcorpan_> id='', class='' and lang='' and what other attribute i'm forgetting, if any, should have been superglobal attributes with predefined semantics in xml
  165. # [03:07] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  166. # [03:07] <SadEagle> othermaciej: as does the DOM3 idea of multiple id attributes..
  167. # [03:07] <othermaciej> zcorpan_: that would have been better
  168. # [03:07] <othermaciej> zcorpan_: and xml:whitespace should have been omitted
  169. # [03:08] <SadEagle> ah, an another thing that sucks is the DOM special-casing of xml and xmlns attributes...
  170. # [03:08] <othermaciej> sorry, xml:space
  171. # [03:08] <SadEagle> it's specified to be completely oblivious to prefix and namespace binding -- except in one case...
  172. # [03:09] <SadEagle> xml:space --- is that the one that affects parsing?
  173. # [03:09] <zcorpan_> only if you're stipping whitespace
  174. # [03:10] <zcorpan_> with is a design problem in itself
  175. # [03:10] * SadEagle looks it up... sounds... extraneous
  176. # [03:11] <zcorpan_> i mean the design problem is that whitespace in xml can either be content or pretty-print
  177. # [03:12] <zcorpan_> html has that too, though
  178. # [03:18] <zcorpan_> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cscript%3Edocument.createElement('header')%3C%2Fscript%3E%0D%0A%3Cbody%3E%3CHEADER%3Ea%3C%2Fheader%3Eb%3Cx%3Aheader%3Ec%3C%2FX%3AHEADER%3Ed
  179. # [03:20] <zcorpan_> oh, nm. i thought ie did something interesting there but it doesn't
  180. # [03:22] <Dashiva> Luckily ElementTraversal will save us from at least parts of the whitespace mess
  181. # [03:30] <SadEagle> from having to write loops?
  182. # [03:36] <zcorpan_> weird ie bug: <?xml-stylesheet type='text/css'?><x>&amp;auml;</x>
  183. # [03:39] <zcorpan_> it can be carried further...
  184. # [03:39] <zcorpan_> y { color:red }
  185. # [03:40] <zcorpan_> <?xml-stylesheet type='text/css' href='test.css'?><x>&lt;y>TEST</x>
  186. # [03:46] <zcorpan_> or <?xml-...?><y>&lt;x> f<test>oo &lt;z> b</test>ar &lt;/x> baz &lt;z></y>
  187. # [03:50] <zcorpan_> acid2 breaks in almost standards mode
  188. # [03:51] <othermaciej> will IE8 have standards/almost standards versions of IE8 mode, I wonder?
  189. # [03:52] <zcorpan_> would make sense if they do what hsivonen proposed
  190. # [03:52] <othermaciej> obviously they won't
  191. # [03:52] <SadEagle> othermaciej: I think i get it now. Their stategy is to get all competing browser vendors to go nuts by trying to figure out what they're doing (oops, I think they might have tried it before)
  192. # [03:59] <zcorpan_> acid2 looks surprisingly similar in almost standards mode across fx, opera and safari. in fact i think they're actually pixel perfectly the same
  193. # [04:02] <zcorpan_> quirks mode is a bit different though, but fx and safari are pretty alike
  194. # [04:13] <othermaciej> I think Opera's quirks mode is somewhat more IE-like
  195. # [04:14] * Quits: weinig_ (n=weinig@17.203.15.140)
  196. # [04:15] <zcorpan_> yeah
  197. # [04:17] <othermaciej> but yes, non-IE browsers are surprisingly similar even on things that aren't specifically standard
  198. # [04:17] <othermaciej> especially considering how vague many of the controlling standards are
  199. # [04:22] * Quits: weinig (n=weinig@nat/apple/x-fd58814305137fbb)
  200. # [04:25] <zcorpan_> i should probably get along with writing my quirks spec so we can get a smiling acid quirks face cross-browser
  201. # [04:36] <othermaciej> IE changing their quirks mode seems pretty unlikely
  202. # [04:37] * Parts: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
  203. # [04:37] <zcorpan_> still, other browsers can interoperate
  204. # [04:39] * zcorpan_ thinks quirks mode deserves more attention, given that it affects the vast majority of authors
  205. # [04:40] <othermaciej> it does
  206. # [04:40] <othermaciej> no question
  207. # [04:40] <othermaciej> interop is good
  208. # [04:40] <othermaciej> but caring about interop seems inversely proportional to market share, which is a little unfortunate
  209. # [04:40] <SadEagle> cutting down on reverse-engineering time is good, too
  210. # [04:41] <othermaciej> yes, good standards ensure long-term competitiveness in the face of new entrants
  211. # [04:41] <othermaciej> there hasn't been a serious new browser engine developed in some time
  212. # [04:42] <othermaciej> and many older ones have died out
  213. # [04:44] <SadEagle> well, what's the financial incentive, anyway?
  214. # [04:45] <SadEagle> there are good ones available under reasonable licensing terms for free, and I don't know about how much of differentiation one can get
  215. # [05:00] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  216. # [05:05] <othermaciej> true, doesn't seem like much incentive for a new one
  217. # [05:11] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  218. # [05:12] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  219. # [05:13] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net) (Remote closed the connection)
  220. # [05:25] <MikeSmith> hsivonen, annevk (+whoever else might care) - deadline for submitting proposals for XTech has been extended to Monday
  221. # [05:25] <MikeSmith> http://2008.xtech.org/public/cfp/9
  222. # [05:31] <MikeSmith> I'm writing a proposal for a presentation that looks at what substantial changes have been made to various browser engines over the last since (since XTech 2007 last May)
  223. # [05:33] * Quits: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com) ("Konversation terminated!")
  224. # [05:38] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  225. # [06:25] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  226. # [06:25] * Joins: roc (n=roc@64.156.190.240)
  227. # [06:26] <zcorpan_> "Style sheet data (%StyleSheet; in the DTD) can be the content of the STYLE element and the value of the style attribute. User agents must not evaluate style data as HTML markup."
  228. # [06:26] <zcorpan_> http://www.w3.org/TR/REC-html40/types.html#h-6.15
  229. # [06:26] <zcorpan_> that means that entities and NCRs in style='' must not be resolved
  230. # [06:27] <zcorpan_> no?
  231. # [06:30] * Joins: jnbdz_ (n=chatzill@modemcable202.23-37-24.mc.videotron.ca)
  232. # [06:31] <Ketsuban> * zcorpan_ thinks quirks mode deserves more attention, given that it affects the vast majority of authors <- doesn't it defeat the object to create a standard for quirks mode?
  233. # [06:32] <zcorpan_> i don't follow
  234. # [06:48] * Joins: cgriego (n=cgriego@cpe-76-183-49-187.tx.res.rr.com)
  235. # [06:48] * Quits: cgriego (n=cgriego@cpe-76-183-49-187.tx.res.rr.com) (Client Quit)
  236. # [06:53] <Ketsuban> zcorpan_: The whole point of quirks mode is that it's quirky - it doesn't follow any standards except the standards of the writer of the browser.
  237. # [06:54] <othermaciej> Ketsuban: the point of quirks mode is compatibility
  238. # [06:54] <othermaciej> (I'd call it "compatibility mode" if I were naming it)
  239. # [07:35] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  240. # [07:45] * Joins: a-ja (n=chatzill@adsl-70-237-206-79.dsl.stlsmo.sbcglobal.net)
  241. # [08:05] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  242. # [08:42] * Joins: webben (n=benh@91.84.237.93)
  243. # [08:45] * Quits: jnbdz_ (n=chatzill@modemcable202.23-37-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  244. # [08:46] <jruderman> Hixie: are there specs that say whether https://bugzilla.mozilla.org/show_bug.cgi?id=340017 is a bug?
  245. # [08:47] <othermaciej> jruderman: no specs define the document.formName behavior
  246. # [08:48] <jruderman> ok
  247. # [08:48] <jruderman> i'd prefer for it to work in XHTML because i don't want there to be too many differences between HTML and XHTML
  248. # [08:52] <jruderman> https://bugzilla.mozilla.org/show_bug.cgi?id=371711 would be a fun one to have in acid3
  249. # [08:55] <jruderman> https://bugzilla.mozilla.org/show_bug.cgi?id=378666 too
  250. # [08:59] <othermaciej> jruderman: putting things directly on window or document based on the markup is pretty dodgy because it creates namespace risk when those APIs are extended
  251. # [08:59] <othermaciej> jruderman: so I wouldn't feel too sad about XHTML phasing that practice out
  252. # [09:00] <jruderman> ok
  253. # [09:07] <MacDomeOut> ed_home: http://bugs.webkit.org/show_bug.cgi?id=16968
  254. # [09:07] * MacDomeOut is now known as MacDome
  255. # [09:07] <MacDome> ed_home: Hixie used data: urls for load guarantees
  256. # [09:08] <MacDome> otherwise he'd have to use an additional <iframe> and re-write all his traversal tests to be aware of said iframe
  257. # [09:08] <MacDome> doing a dynamic insertion would not guarantee it to load fast enough
  258. # [09:15] <jruderman> https://bugzilla.mozilla.org/show_bug.cgi?id=393340 confuses me
  259. # [09:23] <weinig> MacDome: why would there need to be a guaranteed load speed? could the iframe simply call a function in it's parent to notify that it had finished loading?
  260. # [09:23] <MacDome> weinig: if the load is kicked off from teh test, part of Acid3 is that the anim shoudl be fluid
  261. # [09:23] <MacDome> so either the load needs to be done before any tests
  262. # [09:24] <MacDome> or the load needs to be basically instant
  263. # [09:24] <MacDome> weinig: I think Hixie had most recently decided to just add a "load up things" phase, which did all the loads (via js) after the onload, but before starting the tests
  264. # [09:24] * jwalden sorta disagrees
  265. # [09:24] <jwalden> class += "P"
  266. # [09:25] <jwalden> as long as they happen, smoothness not so much a concern to me
  267. # [09:25] <weinig> MacDome: is there any spec that states that data: urls are loaded synchronously?
  268. # [09:25] <MacDome> weinig: no, that part has nothing to do with data loads
  269. # [09:25] <weinig> MacDome: nm
  270. # [09:25] <jwalden> does *any* URL load sync?
  271. # [09:25] <MacDome> it has to do with not being able to use external loads
  272. # [09:25] <jwalden> I'm not aware of anything
  273. # [09:25] <weinig> that was a dumb question
  274. # [09:26] <MacDome> src="foo.svg"
  275. # [09:26] <MacDome> load speed should not affect animation speed
  276. # [09:26] <MacDome> at least resource fetch speed shouldn't
  277. # [09:26] <MacDome> that's not the point of the test
  278. # [09:27] <MacDome> so he needs to preload them, or use data urls
  279. # [09:27] <MacDome> he didn't want to edit the actual source (since that would change the traversed dom)
  280. # [09:27] <MacDome> so he needs to add a pre-load phase
  281. # [09:27] <MacDome> a "load up everything before actually kicking off the tests" phase
  282. # [09:32] <hsivonen> jwalden: re: constant-time indexing and UTF-32, roc has a good blog post about why string indexing misses the point
  283. # [09:32] <jwalden> that it does isn't the point
  284. # [09:32] <jwalden> er
  285. # [09:33] <jwalden> I think it's a reasonable tradeoff in the long haul
  286. # [09:33] <jwalden> memory is cheap
  287. # [09:33] <jwalden> and getting cheaper
  288. # [09:34] <roc> gah
  289. # [09:35] <jwalden> although
  290. # [09:36] <jwalden> it makes more sense as an internal format than as something you'd send over the network
  291. # [09:36] <roc> memory may be cheap but memory bandwidth, cache and CPU arne't
  292. # [09:37] <jwalden> sure
  293. # [09:37] <roc> and maybe we should use memory for useful stuff instead of just wasting up
  294. # [09:37] <roc> then there's mobile
  295. # [09:37] <jwalden> for some work loads that may not matter
  296. # [09:37] <hsivonen> jwalden: in any case, sending UTF-32 over the network makes absolutely no sense
  297. # [09:37] <hsivonen> jwalden: only test suites do it
  298. # [09:38] <hsivonen> jwalden: and if browsers support it and sites other than test suites use it for whatever misguided reason, non-browser scrapers need to add UTF-32
  299. # [09:39] <hsivonen> and if the UTF-32 decoder doesn't exist as part of the platform, implementing it is a remarkable bad use of developer time
  300. # [09:40] <hsivonen> jwalden: IIRC, the UTF-32 should not was put in the spec after Mike Day pointed out that implementing UTF-32 support in Prince would have been useless use of dev time
  301. # [09:42] <hsivonen> UTF-32 has already wasted my time since the JDK doesn't support it but ICU4J does and I want the V.nu parser to be usable on pure JDK but also use ICU4J when available
  302. # [09:52] * Joins: eseidel_ (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  303. # [10:09] * Joins: a-ja_ (n=chatzill@70.230.159.56)
  304. # [10:28] * Quits: a-ja (n=chatzill@adsl-70-237-206-79.dsl.stlsmo.sbcglobal.net) (Read error: 110 (Connection timed out))
  305. # [10:29] * a-ja_ is now known as a-ja
  306. # [10:31] * Quits: roc (n=roc@64.156.190.240)
  307. # [10:37] * Quits: takkaria (n=takkaria@isparp.co.uk) ("Lost terminal")
  308. # [10:37] * Joins: takkaria (n=takkaria@isparp.co.uk)
  309. # [10:43] * Joins: ROBOd (n=robod@89.122.216.38)
  310. # [11:40] * Joins: maikmerten (n=maikmert@T7eda.t.pppool.de)
  311. # [11:54] * Quits: jgraham (n=james@81-86-219-94.dsl.pipex.com) ("This computer has gone to sleep")
  312. # [12:03] * Quits: psa (n=yomode@71.93.19.66) (Remote closed the connection)
  313. # [12:05] * Joins: jgraham (n=jgraham@81-86-219-94.dsl.pipex.com)
  314. # [12:05] <hsivonen> http://en.wikipedia.org/wiki/HTML#Elements
  315. # [12:05] <hsivonen> "label" hmmkay
  316. # [12:10] * Quits: ed_home (n=ed_japan@1-1-4-33a.lk.lk.bostream.se) (Read error: 104 (Connection reset by peer))
  317. # [12:11] * Joins: ed_japan (n=ed_japan@1-1-4-33a.lk.lk.bostream.se)
  318. # [12:24] * Joins: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  319. # [12:33] * Joins: doublec (n=Chris_Do@203-97-173-6.cable.telstraclear.net)
  320. # [12:36] * Quits: doublec (n=Chris_Do@203-97-173-6.cable.telstraclear.net) (Client Quit)
  321. # [12:41] * Quits: webben (n=benh@91.84.237.93) (Read error: 110 (Connection timed out))
  322. # [13:04] * MacDome is now known as MacDomeSleep
  323. # [13:04] * Quits: eseidel_ (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  324. # [13:15] * Joins: tndH_ (i=Rob@83.100.254.128)
  325. # [13:15] * tndH_ is now known as tndH
  326. # [13:16] * Joins: virtuelv (n=virtuelv@65.80-202-82.nextgentel.com)
  327. # [13:28] <ed_japan> MacDomeSleep: dataURI:s may load faster but I don't know if that's guaranteed, I think having them like that is fine but it's probably better to preload the necessary resources before starting the test
  328. # [13:28] * ed_japan is now known as ed_home
  329. # [13:28] <MacDomeSleep> ed_home: I expet that's what Hixie is planning on doing
  330. # [13:28] <MacDomeSleep> ed_home: the data: load is expected to be synchronous I bet
  331. # [13:32] <annevk> it's not
  332. # [13:32] <annevk> it's just expected to take very little time
  333. # [14:02] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  334. # [14:09] <gsnedders> hsivonen: for the validator, how do you know whether to use ISO-8859-1 or Windows-1252?
  335. # [14:11] <annevk> isn't ISO-8859-1 just an alias?
  336. # [14:13] <gsnedders> he lists both in the options
  337. # [14:13] <gsnedders> is ISO-8859-1 only ever sniffed as Windows-1252 so to validate using ISO-8859-1 you need to explicitly use it?
  338. # [14:25] * Quits: virtuelv (n=virtuelv@65.80-202-82.nextgentel.com) ("Leaving")
  339. # [14:32] <hsivonen> gsnedders: the override overrides the HTTP layer encoding info
  340. # [14:32] <hsivonen> gsnedders: the result follow from that
  341. # [14:33] <hsivonen> gsnedders: so it is an alias in the HTML case but different encoding in the XML case
  342. # [14:33] <gsnedders> ah.
  343. # [14:33] <hsivonen> I could be persuaded to take ISO-8859-1 off the menu
  344. # [14:35] <gsnedders> I found some many mis-served feeds that I treat ISO-8859-1 as Windows-1252 in XML too, FWIW
  345. # [14:50] <annevk> making ISO-8859-1 an alias for Windows-1252 "globally" seems like the most practical solution
  346. # [14:51] <gsnedders> anyone want to try and register that? :P
  347. # [14:52] <Philip`> Surely ISO wouldn't mind updating their spec to better match reality
  348. # [14:53] * gsnedders dunnos
  349. # [14:54] <hsivonen> from the usability point of view, though, should I keep the menu item?
  350. # [14:54] <hsivonen> browsers keep the menu item
  351. # [14:55] <hsivonen> but a validator is aimed at a different audience
  352. # [14:58] <gsnedders> Philip`: Hmm, I doubt we could get ISO-8859-1 changed. We have more hope at getting the IANA to register it as an alias.
  353. # [14:59] <hsivonen> gsnedders: I don't think the IANA subscribes to WHATWG principles yet
  354. # [14:59] <gsnedders> Nor do I.
  355. # [14:59] <gsnedders> All I said is "more hope", not having much :)
  356. # [15:06] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  357. # [15:11] <annevk> maybe we should have an alternative to IANA on the WHATWG wiki (A)
  358. # [15:11] <gsnedders> :D
  359. # [15:12] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  360. # [15:28] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  361. # [15:33] * Quits: a-ja (n=chatzill@70.230.159.56) ("Chatzilla 0.9.77-rdmsoft [XULRunner 1.8.0.4/2006060814]")
  362. # [16:08] * Joins: jgraham_ (n=james@cpc2-farn1-0-0-cust756.glfd.cable.ntl.com)
  363. # [16:08] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  364. # [16:12] <hsivonen> hmm. Looks like Shelley Powers went application/xhtml+xml-only even for IE
  365. # [16:13] <hsivonen> I wonder if others who write reading-worthy stuff follow her lead
  366. # [16:13] <annevk> maybe I should start serving up style sheets using Link:
  367. # [16:14] <hsivonen> annevk: that's a bit different, though
  368. # [16:14] <hsivonen> Link was removed from HTTP 1.1
  369. # [16:15] <webben_> hsivonen: hmm, when I curl http://burningbird.net/ I get text/html.
  370. # [16:15] <webben_> "XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN" served as text/html to be precised
  371. # [16:15] <webben_> *precise
  372. # [16:15] <hsivonen> webben_: ah. I only tried realtech.burningbird.net (checked with IE UA string and Accept: text/html)
  373. # [16:26] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  374. # [16:32] * Joins: heycam` (n=cam@203-217-73-2.dyn.iinet.net.au)
  375. # [16:39] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  376. # [16:44] * Quits: heycam (n=cam@124-168-58-127.dyn.iinet.net.au) (Read error: 101 (Network is unreachable))
  377. # [16:44] * Quits: jwalden (n=waldo@RANDOM-THREE-O-EIGHT.MIT.EDU) (Remote closed the connection)
  378. # [16:59] <zcorpan_> this is probably the sneakiets spam i've ever seen... http://forums.whatwg.org/viewtopic.php?t=134
  379. # [16:59] <zcorpan_> well, at least on f.w.o
  380. # [17:00] * Joins: jnbdz_ (n=chatzill@modemcable202.23-37-24.mc.videotron.ca)
  381. # [17:01] <zcorpan_> "Hello!
  382. # [17:01] <zcorpan_> Could you tell me a portal where I can add advertisements for printing and graphic art machines free?
  383. # [17:01] <zcorpan_> Here’s one www.allf...."
  384. # [17:14] * Quits: Kuruma (n=Kuruman@h123-176-107-050.catv01.catv-yokohama.ne.jp) (Read error: 104 (Connection reset by peer))
  385. # [17:16] * Joins: Kuruma (n=Kuruman@h123-176-107-050.catv01.catv-yokohama.ne.jp)
  386. # [17:23] <zcorpan_> hsivonen: i fixed the terminology on the wikie page. well, only in that section. we'll see if someone reverts it or fixes the rest
  387. # [17:23] <zcorpan_> s/wikie/wiki/
  388. # [17:24] <hsivonen> zcorpan_: thanks
  389. # [17:25] <hsivonen> earlier today, I added mentions of the HTML5 WD to wikipedia
  390. # [17:25] <hsivonen> I'm slightly surprised that the hive mind hadn't taken care of it
  391. # [17:26] <hsivonen> or it had for "HTML 5" but not for "HTML" and "XHTML"
  392. # [17:41] * Joins: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  393. # [17:51] <hsivonen> I could waste the whole weekend if I wanted to fix what the Finnish Wikipedia says about HTML matters
  394. # [17:51] <hsivonen> :-(
  395. # [17:52] <annevk> give it a few years
  396. # [17:52] <annevk> there's no hurry
  397. # [17:59] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  398. # [18:01] <hsivonen> the quality of Web-related articles on the Finnish wikipedia is really sad
  399. # [18:02] <hsivonen> I guess the people who care are literate in English and prefer to play in the bigger sandbox
  400. # [18:02] <hsivonen> like me
  401. # [18:02] <annevk> whoa
  402. # [18:03] <annevk> i just noticed that the guy who asked about extensibility is from microsoft
  403. # [18:03] * Quits: maikmerten (n=maikmert@T7eda.t.pppool.de) ("Leaving")
  404. # [18:04] <annevk> it does say so pretty clearly at the bottom of http://lists.w3.org/Archives/Public/public-html-comments/2008Jan/0038.html but then I don't read very well :o
  405. # [18:04] <annevk> i guess my answer would still have been pretty much the same
  406. # [18:05] <hsivonen> annevk: I think your answer missed the point
  407. # [18:06] <hsivonen> annevk: the way I read it was that (s)he wanted to add custom elements to bind the XBL stuff to
  408. # [18:06] <annevk> from http://www.nikhilk.net/HTML5-Thoughts.aspx I gathered that it was also about XBL
  409. # [18:06] <annevk> or HTC
  410. # [18:07] <annevk> " I would have loved to see the HTML 5 spec address extensibility of the tag set and rationalize things like HTC behaviors and XBL bindings."
  411. # [18:07] <annevk> though maybe I misunderstand "rationalize"
  412. # [18:08] <hsivonen> I think it means that XBL is kind of pointless as an implementation mechanism for custom elements if HTML5 doesn't allow you to create custom elements
  413. # [18:08] <annevk> ah ok
  414. # [18:09] <annevk> he has some thoughts on <dialog> too: http://www.nikhilk.net/HTML5-Dialog-Microformats.aspx
  415. # [18:09] * SadEagle reads the charset thread and wonders whether some people would have a different opinion if they were not from Western Europe
  416. # [18:10] * Joins: dbaron (n=dbaron@c-71-204-145-103.hsd1.ca.comcast.net)
  417. # [18:11] <hsivonen> SadEagle: UTF-8 covers all of Unicode and Western Europe has a legacy to get rid of, too
  418. # [18:14] <SadEagle> hsivonen: sure. But e.g. I can tell you that for Cyrillic (at least Russian), it used to be a real mess (and still parly is) --- some of the bigger websites would have proxies to automatically recode things into different encoding, including transliteration into latin..
  419. # [18:14] <hsivonen> SadEagle: I know. Are we talking about the same thread?
  420. # [18:14] <SadEagle> hsivonen: probably.... ... and despite having 2+ codes in wide uses, a lot of websites would not specify their encoding, so good encoding autoguessing is actually a part of interoperability needs :(
  421. # [18:16] <hsivonen> SadEagle: yeah, failure to declare the encoding is a very, very bad idea.
  422. # [18:16] <hsivonen> I was referring to the public-html-comments thread.
  423. # [18:17] <SadEagle> yeah, me too. BTW, on the link to verifier you added... apparently some people actually use MacCyrrilic. Not too many, thankfully.
  424. # [18:18] <SadEagle> (I don't think i've seen anyone use 8859-5, though)
  425. # [18:20] <hsivonen> SadEagle: apparantly no one has cared enough to register MacCyrillic with the IANA, so it's not on the list
  426. # [18:20] * Joins: virtuelv (n=virtuelv@65.80-202-82.nextgentel.com)
  427. # [18:20] <hsivonen> and, yes, the Web might not break if ISO-8859-5 were not supported
  428. # [18:20] <hsivonen> but then, it is supported and registered, so it is on my list
  429. # [18:22] <hsivonen> SadEagle: btw, that list is the intersection of the IANA registry, Python 2.4 (or 2.3 I forget), Sun JDK 1.4.2, IE 7, Firefox 2, Safari 2 and Opera 9
  430. # [18:22] <hsivonen> minus US-ASCII which doesn't make sense as an override
  431. # [18:23] <SadEagle> sounds reasonable, expect you probably have to union in IE6 :(
  432. # [18:24] <hsivonen> if that add encodings, they are probably seriously in the diminishing returns department and cover very little Web content
  433. # [18:24] <hsivonen> s/add/adds/
  434. # [18:26] <hsivonen> in any case, my point is that the proliferation is bad and BOCU-1 is not part of the real Web content legacy
  435. # [18:27] <SadEagle> I guess my point is that you won't have to explain that to people who had to deal with a whole bunch of encoding legacy :-)
  436. # [18:33] * Joins: jwalden (n=waldo@RANDOM-SEVENTY-TWO.MIT.EDU)
  437. # [18:34] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  438. # [18:36] * Quits: vant (n=vant@p2098-ipbf4207marunouchi.tokyo.ocn.ne.jp) (Read error: 110 (Connection timed out))
  439. # [18:46] * Joins: tndH_ (n=Rob@83.100.254.150)
  440. # [19:09] * Quits: tndH (i=Rob@83.100.254.128) (Read error: 110 (Connection timed out))
  441. # [19:10] * Joins: roc (n=roc@64.156.190.240)
  442. # [19:37] * weinig is now known as weinig|away
  443. # [19:41] * Quits: Ketsuban (n=ketsuban@cpc2-oxfd8-0-0-cust335.oxfd.cable.ntl.com) (Read error: 113 (No route to host))
  444. # [19:44] <hsivonen> the WHATWG wiki doesn't have Atom feeds like wikipedia
  445. # [19:44] <hsivonen> can I get email notifications from the WHATWG wiki when it is edited?
  446. # [19:45] * Joins: Ketsuban (n=ketsuban@cpc2-oxfd8-0-0-cust335.oxfd.cable.ntl.com)
  447. # [19:45] <hsivonen> hmm. looks like I already have that enabled. the wiki just isn't edited often
  448. # [19:54] * Joins: marcreichelt (n=marc@p54B1C87F.dip.t-dialin.net)
  449. # [19:54] <marcreichelt> hi there :)
  450. # [19:54] <marcreichelt> I have a question about HTML 5
  451. # [19:55] <marcreichelt> is there a rational reason for the <embed> element being part of the new HTML 5 draft?
  452. # [19:56] * Joins: starjive (i=beos@81-233-18-73-no30.tbcn.telia.com)
  453. # [19:56] <marcreichelt> because then there would be 2 elements for embedding random content - <embed> and <object>
  454. # [19:57] <SadEagle> that's the least of problems with embed :-)
  455. # [19:58] <annevk> <object> is a generic inclusion mechanism, <embed> is for plugins
  456. # [19:58] <annevk> so <embed> is actually a specific form of <object>, just like <img>
  457. # [19:59] <hsivonen> marcreichelt: content authors need embed to support existing browsers, so we might as well make it valid
  458. # [19:59] <marcreichelt> which browser needs embed today?
  459. # [19:59] <SadEagle> all of them
  460. # [19:59] <marcreichelt> besides, Netscape is dead
  461. # [19:59] <SadEagle> if you mean from the browser side, not author side
  462. # [19:59] <annevk> yes, but <embed> isn't :)
  463. # [19:59] <marcreichelt> and all the multimedia content can be embedded via object, too
  464. # [20:00] <SadEagle> annevk: <lazy>does html5 still do the evil embed-in-object thing though</lazy> ?
  465. # [20:00] <marcreichelt> :(
  466. # [20:00] <annevk> SadEagle, <object> can have <embed>, sure
  467. # [20:01] <hsivonen> embed in object is still needed to make Flash work in both IE and Firefox
  468. # [20:01] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  469. # [20:01] <marcreichelt> no
  470. # [20:01] <marcreichelt> it is not
  471. # [20:01] <SadEagle> annevk: but is there any special behavior outside of normall fallback content there?
  472. # [20:01] <hsivonen> marcreichelt: can you get one object to work in both with accessibility stuff and all?
  473. # [20:02] <marcreichelt> oh - I think I know what you are talking about
  474. # [20:02] <marcreichelt> so you are taking <embed> in because of the accessibility?
  475. # [20:03] <marcreichelt> if HTML 5 wouldn't have <embed> in it, the creators of accessibility programs (like YAWS) will definitely fix this
  476. # [20:04] <hsivonen> marcreichelt: I can't say what rationale Hixie had, but from my point of view, admitting that it exists and making it conforming is more productive than embarking on a massive re-education campaign
  477. # [20:04] <marcreichelt> the support of two elements (object AND embed) is just not reasonable to me
  478. # [20:04] <marcreichelt> :(
  479. # [20:04] <hsivonen> marcreichelt: browsers other than IE will have to support both no matter what the spec says
  480. # [20:04] <hsivonen> marcreichelt: it is mainly an issue of whether we admit <embed> as conforming
  481. # [20:05] <marcreichelt> "browsers other than IE"
  482. # [20:05] <marcreichelt> ?
  483. # [20:06] <hsivonen> marcreichelt: evidence shows MS can get away with doing something different
  484. # [20:06] <marcreichelt> my argument is: if you will conform the embed-Element, the evil embed-in-object thing will live long and prosper
  485. # [20:06] <hsivonen> what's evil about it?
  486. # [20:07] <marcreichelt> you have to embed the same content twice
  487. # [20:07] <marcreichelt> and the parameters of embed and object have to be kept twice
  488. # [20:08] <marcreichelt> this is a great source for errors (why does IE play my flash movie, but Firefox does not?)
  489. # [20:09] <SadEagle> marcreichelt: actually, you only need most stuff on the embed
  490. # [20:09] <SadEagle> object will automatically pick stuff up from it.
  491. # [20:10] * weinig|away is now known as weinig
  492. # [20:10] <marcreichelt> right now, special parameters for embed are passed by non-conform attributes
  493. # [20:10] <marcreichelt> for object, there is the <param>-Tag
  494. # [20:11] * Quits: jgraham_ (n=james@cpc2-farn1-0-0-cust756.glfd.cable.ntl.com) ("This computer has gone to sleep")
  495. # [20:13] <hsivonen> marcreichelt: it is kind of pointless to change HTML5 if https://bugzilla.mozilla.org/show_bug.cgi?id=46569 doesn't get reversed and the current installed based replaced
  496. # [20:14] <hsivonen> marcreichelt: HTML5 makes the embed attributes conforming, so they're no longer non-conform :-)
  497. # [20:14] <marcreichelt> hsivonen: and what about the parameters for the content?
  498. # [20:15] <hsivonen> marcreichelt: they are conforming, too, per HTML5
  499. # [20:15] <marcreichelt> just look at the standard-embed for any multimedia (Flash or something like that) content
  500. # [20:15] <marcreichelt> for example flash:
  501. # [20:15] <marcreichelt> http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_4150&sliceId=2
  502. # [20:15] <marcreichelt> <embed> is not like <embed src="..." type="..." width="..." height="..." />
  503. # [20:15] <marcreichelt> but like:
  504. # [20:16] <marcreichelt> <embed src="..." type="..." width="..." height="..." bgcolor="..." pluginspage="..." quality="..." fooattribute="..." />
  505. # [20:16] <hsivonen> marcreichelt: the errors I got from Validator.nu pertain to classid, codebase and the end tag </embed>
  506. # [20:17] <hsivonen> marcreichelt: the spec allows that stuff
  507. # [20:17] <marcreichelt> wohw?
  508. # [20:17] <marcreichelt> no :(
  509. # [20:17] <marcreichelt> ok, thats it
  510. # [20:17] <marcreichelt> HTML 5 is no goot to me
  511. # [20:17] <marcreichelt> -t+d
  512. # [20:17] <SadEagle> marcreichelt: the point is interoperability.
  513. # [20:18] <marcreichelt> so I believe <embed> can take _any_ attribute?
  514. # [20:18] <hsivonen> marcreichelt: yes
  515. # [20:18] <marcreichelt> wahh
  516. # [20:18] <marcreichelt> ok
  517. # [20:18] <SadEagle> people don't write nice mark up. This sort of thing is one the web, and it'll be on the web regardless of what html5 says
  518. # [20:18] <marcreichelt> great
  519. # [20:18] <hsivonen> marcreichelt: or, rather, any attribute that is not in a namespace
  520. # [20:18] <marcreichelt> is this allowed for other elements, too?
  521. # [20:18] <hsivonen> marcreichelt: no
  522. # [20:18] <marcreichelt> kay
  523. # [20:19] <hsivonen> marcreichelt: the W3C tried to kill <embed> a decade ago
  524. # [20:19] <hsivonen> marcreichelt: <embed> is still around so we might as well admit that killing it didn't work
  525. # [20:20] <marcreichelt> or maybe there has not been enough time
  526. # [20:20] <hsivonen> marcreichelt: is getting rid of <embed> really worth a more than a decade of trying?
  527. # [20:20] <marcreichelt> yes
  528. # [20:20] <SadEagle> it won't happen.
  529. # [20:21] <marcreichelt> it is worth to me if I see complex constructions like the embed-in-object
  530. # [20:21] <marcreichelt> and users that are confused why they have to type in the same information twice
  531. # [20:21] <SadEagle> marcreichelt: it's even uglier on the implementation end, but the implementors will have to support it /anyway/. So it's better to bring some order to it.
  532. # [20:22] <marcreichelt> if you say so
  533. # [20:22] <marcreichelt> you are the master
  534. # [20:22] <marcreichelt> ;)
  535. # [20:22] <SadEagle> I am not :-). Well, I sort of am on the "ugly on the implementation end" part..
  536. # [20:23] <marcreichelt> k
  537. # [20:23] <marcreichelt> for which implementation if I may ask?
  538. # [20:24] <SadEagle> khtml.
  539. # [20:24] <marcreichelt> ah, okay :)
  540. # [20:25] <SadEagle> I think it can be simplified by taking advantage of fallback content, though
  541. # [20:25] <marcreichelt> all I can say is that having the embed element is not good for a longer time
  542. # [20:25] <hsivonen> marcreichelt: Flash itself is a much bigger problem than the entry point
  543. # [20:25] <marcreichelt> and there is no alternative content for <embed>, right?
  544. # [20:25] <gsnedders> right.
  545. # [20:26] <hsivonen> marcreichelt: the main use case for <embed> is Flash and the right way to do Flash accessibility is to have the Flash player talk to the accessibility framework
  546. # [20:27] <marcreichelt> so the alternative content of the <object> element will always be an <embed> element
  547. # [20:27] <hsivonen> pretty much, yes.
  548. # [20:28] <marcreichelt> so in the case no Flash Player is installed there will be no alternative content
  549. # [20:29] <hsivonen> marcreichelt: right
  550. # [20:29] <SadEagle> marcreichelt: and actually, part of the problem for a minor developer is that one has to reverse-engineer this sort of stuff... So having it written down helps
  551. # [20:29] <hsivonen> marcreichelt: evidence suggests that authors either don't care or provide an <a href link to alternative content
  552. # [20:30] <marcreichelt> why don't they care?
  553. # [20:30] <marcreichelt> because it is not possible right now
  554. # [20:30] <hsivonen> marcreichelt: and Flash being proprietary is the real problem behind Flash not being installed somewhere
  555. # [20:30] <marcreichelt> because the alternative content for an object element will be an embed element
  556. # [20:31] <SadEagle> marcreichelt: is impossibility why many websites don't have "well-structured" markup?
  557. # [20:31] <hsivonen> marcreichelt: ad hoc analysis suggests that Flash is often used for marketing and if marketers care about alternative content, they think of SEO first
  558. # [20:32] <hsivonen> marcreichelt: marketers usually don't care about FreeBSD on MIPS or other platforms that don't run Flash
  559. # [20:33] <hsivonen> marcreichelt: and like I said, alternative content isn't the right way to do Flash accessibility
  560. # [20:33] <marcreichelt> no - not do do Flash accessibility
  561. # [20:33] <gsnedders> hsivonen: heck, they don't care about Windows x64, yet alone FreeBSD on MIPS
  562. # [20:33] <hsivonen> gsnedders: good point
  563. # [20:35] <marcreichelt> okay then
  564. # [20:35] <hsivonen> basically, to do what's done with Flash but in a non-proprietary way, there are <canvas>, <video> and <svg>
  565. # [20:35] <marcreichelt> I think there is no possibility to change this
  566. # [20:44] <marcreichelt> see you
  567. # [20:44] * Quits: marcreichelt (n=marc@p54B1C87F.dip.t-dialin.net) ("HTML 5 - the war between <object> and <embed> continues...")
  568. # [20:46] <harri> annevk: you had been writing some xmlhttprequest tests, right?
  569. # [20:49] * Joins: csarven- (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  570. # [20:51] <hsivonen> is there a pure python alternative for pygenx? does html5lib contain one by any chance?
  571. # [21:02] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  572. # [21:07] <hsivonen> hmm. interesting. iCab 4 contains only the Growl framework, which suggests all the features have been implemented with the OS copy of WebKit
  573. # [21:08] * Quits: csarven- (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  574. # [21:10] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  575. # [21:35] * Joins: markp (n=mark@adsl-221-7-211.rmo.bellsouth.net)
  576. # [21:59] * Joins: Thezilch[FH] (i=fuz007@cpe-67-49-89-123.socal.res.rr.com)
  577. # [22:01] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  578. # [22:06] * Quits: markp (n=mark@adsl-221-7-211.rmo.bellsouth.net) (Read error: 113 (No route to host))
  579. # [22:14] * gsnedders realises he's reading the GZIP spec wrong
  580. # [22:15] <gsnedders> the bits are written in big-endian form within a byte, with bytes in little-endian order
  581. # [22:17] * Quits: Thezilch (i=fuz007@cpe-67-49-89-123.socal.res.rr.com) (Connection timed out)
  582. # [22:18] <kig> is there even a system that uses little-endian bit order within byte..
  583. # [22:19] <roc> that never matters
  584. # [22:19] <roc> oh I guess it does for gzip
  585. # [22:21] <gsnedders> it doesn't, AFAIK
  586. # [22:27] <gsnedders> gzip is defined as a sequence of 8-bit bytes, with certain parts being little-endian words
  587. # [22:28] <gsnedders> How you choose to store those bits is up to you.
  588. # [22:30] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  589. # [22:35] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  590. # [22:46] * MacDomeSleep is now known as MacDome
  591. # [22:53] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  592. # [22:53] <zcorpan_> hsivonen: "In that case, you a probably better off tracking XHTML5 as opposed to XHTML 1.1." -- s/a /are /
  593. # [22:59] <annevk> harri, http://tc.labs.opera.com/apis/XMLHttpRequest/
  594. # [23:00] <SadEagle> annevk: I am quite impressive by how you folks don't block the UI on synchronous (puke) XHR
  595. # [23:00] <SadEagle> impressed, that is.
  596. # [23:02] <hsivonen> zcorpan_: thanks. fixed
  597. # [23:03] <jwalden> synchronous APIs are bad
  598. # [23:03] <jwalden> albeit convenient
  599. # [23:03] <jwalden> just gotta bite the bullet
  600. # [23:05] <gsnedders> ABNF isn't expressive enough.
  601. # [23:07] <annevk> SadEagle, that's probably one of my favorite Opera features
  602. # [23:08] <gsnedders> RFC 1952 is too vague.
  603. # [23:11] <hsivonen> annevk: does Presto run in the UI thread nonetheless?
  604. # [23:11] <SadEagle> hmm, looks like we need lots of work on that tc..
  605. # [23:12] <annevk> I'd recommend coding against http://dev.w3.org/2006/webapi/XMLHttpRequest/ and then use the tests to verify
  606. # [23:12] <annevk> so we can catch bugs in both
  607. # [23:12] <annevk> (well, and in your impl :) )
  608. # [23:12] <SadEagle> Well, the code is there, but it could surely use an audit.
  609. # [23:12] <SadEagle> how interoperable is the stuff the tests test?
  610. # [23:12] <annevk> hsivonen, can't comment on that I think
  611. # [23:13] <hsivonen> annevk: ok
  612. # [23:13] <annevk> SadEagle, it's compatible with other browsers
  613. # [23:13] <annevk> I think we aligned with IE the most
  614. # [23:20] <annevk> acid test moved: http://acid3.acidtests.org/
  615. # [23:22] <hsivonen> Hixie: acid3 just crashed my copy of firefox 2
  616. # [23:27] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  617. # [23:28] <annevk> so is text/html;charset=latin1 identical to text/html;charset=iso-8859-1 ?
  618. # [23:30] <hsivonen> annevk: if you use an alias, v.nu will tell you the preferred iana name
  619. # [23:30] <annevk> but aliases are supported and such?
  620. # [23:31] <hsivonen> yes
  621. # [23:31] <hsivonen> http://validator.nu/?doc=http%3A%2F%2Fw3.org%2F&charset=latin1
  622. # [23:31] <hsivonen> yes, latin1 is an alias of iso-8859-1
  623. # [23:32] <hsivonen> oh, did you mean supported in browsers? I'm not sure
  624. # [23:32] <annevk> regarding that document, the lang= attribute value message is confusing
  625. # [23:32] <annevk> yeah, i'd guess so...
  626. # [23:33] <annevk> would be nice if documentation on this sucked less
  627. # [23:34] <annevk> and also exact algorithms for bytestream + encoding -> unicode character stream
  628. # [23:34] <hsivonen> which message is confusing?
  629. # [23:34] <annevk> including handling errors, etc.
  630. # [23:34] <annevk> " Attribute lang not allowed on XHTML element html at this point."
  631. # [23:34] <annevk> where you mean xml:lang probably
  632. # [23:35] <annevk> oh wait
  633. # [23:35] <hsivonen> annevk: no, lang is not allowed
  634. # [23:35] <hsivonen> xml:lang is allowed
  635. # [23:35] <annevk> it's served as XML, blah
  636. # [23:35] * Joins: jgraham_ (n=james@cpc2-farn1-0-0-cust756.glfd.cable.ntl.com)
  637. # [23:35] <hsivonen> hmm. the page has hreflang='en-uk' even
  638. # [23:36] <annevk> i think lang= should be allowed, but i don't care enough to raise it
  639. # [23:36] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  640. # [23:38] <annevk> "XML processors are required to support the UTF-8 and UTF-16 character encodings. The encoding was latin1 instead, which is an incompatibility risk."
  641. # [23:38] <annevk> wasn't that supposedly disabled for ISO-8859-1?
  642. # [23:40] <hsivonen> annevk: yeah, but apparently, the code compares the declared charset--not the canonical name
  643. # [23:41] <hsivonen> which is OK, considering that aliases may not be as safe as "ISO-8859-1"
  644. # [23:42] <hsivonen> compare with http://validator.nu/?doc=http%3A%2F%2Fw3.org%2F&charset=iso-8859-1
  645. # [23:49] <annevk> k
  646. # [23:50] * Quits: virtuelv (n=virtuelv@65.80-202-82.nextgentel.com) (Read error: 110 (Connection timed out))
  647. # [23:52] * Quits: jgraham_ (n=james@cpc2-farn1-0-0-cust756.glfd.cable.ntl.com) ("This computer has gone to sleep")
  648. # Session Close: Sun Jan 27 00:00:00 2008

The end :)