/irc-logs / w3c / #html-wg / 2009-09-19 / end

Options:

  1. # Session Start: Sat Sep 19 00:00:00 2009
  2. # Session Ident: #html-wg
  3. # [00:02] * Joins: J_Voracek (irchon@173.74.232.166)
  4. # [00:03] * Quits: J_Voracek (irchon@173.74.232.166) (Client exited)
  5. # [00:04] * Joins: sryo (sryo@190.245.211.98)
  6. # [00:04] * Quits: sryo (sryo@190.245.211.98) (Connection reset by peer)
  7. # [00:08] <pimpbot> bugmail: [Bug 7551] People are using <section> incorrectly <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Sep/0454.html> ** [Bug 7557] add "type" attribute to <nav> to distinguish between primary and secondary navigation <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Sep/0453.html> ** [Bug 7546] "HTML 5" Editor's draft misnamed and suboptimal for HTML content authors unless refactored into HTML (main) and DOM API
  8. # [00:29] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
  9. # [00:38] <pimpbot> bugmail: [Bug 7542] Remove Section 5. Microdata <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Sep/0455.html>
  10. # [01:15] * Joins: Lachy (Lachlan@85.196.122.246)
  11. # [01:35] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: Leaving)
  12. # [01:35] * Joins: Lachy (Lachlan@85.196.122.246)
  13. # [01:59] * Quits: annevk (opera@83.87.57.202) (Quit: annevk)
  14. # [03:40] * Quits: drunknbass_work (aaron@71.107.253.243) (Quit: Leaving...)
  15. # [04:39] <pimpbot> bugmail: [Bug 7670] Use of prefixes is too complicated for a Web technology <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Sep/0456.html>
  16. # [05:10] * Quits: heycam (cam@210.84.56.211) (Quit: bye)
  17. # [07:10] * Joins: heycam (cam@210.84.56.211)
  18. # [09:37] * Joins: annevk (opera@83.87.57.202)
  19. # [10:11] <pimpbot> bugmail: "[Bug 7670] Use of prefixes is too complicated for a Web technology" (5 messages in thread) <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Sep/0460.html>
  20. # [11:01] * Quits: julian (chatzilla@217.91.35.233) (Ping timeout)
  21. # [11:03] * Joins: julian (chatzilla@217.91.35.233)
  22. # [11:09] <pimpbot> planet: Auckland Web Meetup 2009 <http://weblogs.mozillazine.org/roc/archives/2009/09/auckland_web_me_2.html>
  23. # [11:11] <pimpbot> bugmail: [Bug 7679] New: editorial: "The following content attributes must not be specified" applies to authors but is hidden behind class=impl. It would be helpful if each state listed the attributes that are allowed to be specified for that state. <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Sep/0461.html>
  24. # [11:12] * Joins: ROBOd (robod@89.122.216.38)
  25. # [11:28] <Hixie> there surely is some spec somewhere that defines how to parse mime types
  26. # [11:29] <Hixie> mimesniff defers to HTTP, but HTTP says nothing useful, it only gives authoring conformance criteria
  27. # [11:33] <julian> are you saying that parsing can't be derived from the ABNF?
  28. # [11:38] <Hixie> what is the mime type when the input is "text/ plain " ?
  29. # [11:38] <Hixie> and where is that defined?
  30. # [11:42] <julian> The type is "text" and the subtype is "plain"
  31. # [11:42] <julian> The trailing whitespace is LWS
  32. # [11:44] <Hixie> where does it actually say how you derive the type and subtype from the string? I see grammar tokens "type" and "subtype" but nothing that says that they have any relationship to the actual type and subtype.
  33. # [11:45] <Hixie> what's the mime type if the input is "text//plain"?
  34. # [11:46] <julian> media-type = type "/" subtype *( ";" parameter )
  35. # [11:46] <julian> I think that's as clear as it can be
  36. # [11:46] <Hixie> those tokens are opaque identifiers
  37. # [11:46] <Hixie> the above is exactly equivalent to:
  38. # [11:46] <julian> and "text//plain" doesn't partse according to the ABNF, so it's invalid
  39. # [11:46] <Hixie> xxxxxxxxxx = aaaa "/" bbbbbbb *( ";" ccccccccc )
  40. # [11:47] <julian> Yes, but only if you behave as a spez nazi (tm mplilgrim I think)
  41. # [11:47] <Hixie> how do we know that hte "aaaa" and "bbbbbbb" parts have the semantics of "type" and "subtype"?
  42. # [11:47] <Hixie> ah so you're saying http doesn't actually define this and we have to guess
  43. # [11:47] <Hixie> ok
  44. # [11:47] <julian> we know by using our brain
  45. # [11:47] <Hixie> i agree that we can make educated guesses
  46. # [11:47] <julian> this has nothing to do with guessing
  47. # [11:47] <Hixie> i'm just looking for an actual definition
  48. # [11:48] <Hixie> also, i understand "text//plain" is invalid. i'm asking how to parse it, not how to validate it.
  49. # [11:48] <julian> it has to do woth not insulting the reader by repeating obvious information
  50. # [11:48] <julian> it's a parse error
  51. # [11:49] <Hixie> yes i know it's a parse error
  52. # [11:49] <Hixie> that doesn't answer the question of how you parse it
  53. # [11:49] <Hixie> what's the type and subtype?
  54. # [11:49] <Hixie> is the type "text" and the subtype "/plain"?
  55. # [11:49] <Hixie> and where does the spec define this?
  56. # [11:50] <Hixie> btw, being precise isn't insulting the reader
  57. # [11:50] <Hixie> it's respecting the reader
  58. # [11:52] <Philip> "Linear white space (LWS) MUST NOT be used between the type and subtype, nor between an attribute and its value." - sounds like "text/ plain" is invalid; does that mean it can't be parsed into a type and subtype?
  59. # [11:52] <julian> The spec doesn't specify what to do with invalid input. That's it.
  60. # [11:52] <Hixie> it's clearly invalid, yes
  61. # [11:52] <Hixie> ah, ok
  62. # [11:53] <Hixie> i guess i'll have to define it in html5 then
  63. # [11:53] <Hixie> sigh
  64. # [11:54] <julian> yes, go ahead, waste mor time, and write another 50 line algorithm
  65. # [11:55] <Hixie> defining how things work to get interoperability is not a waste of time
  66. # [11:55] <Hixie> the waste of time is specs that leave this stuff undefined
  67. # [11:59] <Hixie> (i am still sometimes surprised as to how few specs define enough to actually result in truly interoperable behaviour, given how common it is for people to screw things up at all levels)
  68. # [11:59] <Hixie> (especially given the security implications of UAs doing their own thing each time)
  69. # [12:10] <Hixie> wow, i can't find a single user agent that interprets MIME types according to the way julian said the spec implied they should be parsed
  70. # [12:11] <Hixie> so far tried wget, safari, chrome, opera, firefox, and IE8
  71. # [12:11] <julian> please be more specific.
  72. # [12:11] <Hixie> are there any other user agents that support text/html?
  73. # [12:11] <pimpbot> changes: hixie: Make it clear that spaces around the value of type='' on <script> are stripped first, and that the types are compared literally. (whatwg r3909) <http://lists.w3.org/Archives/Public/public-html-diffs/2009Sep/0161.html>
  74. # [12:11] <Hixie> i.e. that process text/html differently than other content?
  75. # [12:12] <julian> Please be more specific in how they behave other than "Julian said"
  76. # [12:13] <Hixie> that treat text/html like text/ html
  77. # [12:13] <julian> if your point is that they accept invalid input: this is not news
  78. # [12:13] <julian> and I didn't say it's illegal to do so
  79. # [12:13] <Hixie> no, i'm testing valid input
  80. # [12:13] <julian> So, please be more specific
  81. # [12:14] <Hixie> so far no tool i have tested has treated "Content-Type: text/ html" as equivalent to "Content-Type: text/html"
  82. # [12:14] <Hixie> they all treat the former as an unknown type
  83. # [12:14] <julian> why should it
  84. # [12:14] <julian> yes, and that that's good; the former is invalid
  85. # [12:14] <Hixie> you just said it was valid
  86. # [12:14] <Hixie> or rather
  87. # [12:14] <julian> no I didn't
  88. # [12:14] <Hixie> you just said the spec said it parsed as type=text, subtype=html
  89. # [12:15] <Hixie> which surely is the same with or without the space
  90. # [12:15] <julian> No, I didn't
  91. # [12:15] <julian> It appears you are confused about what I said; maybe that's my fault.
  92. # [12:15] <julian> The ABNF is clear about it, and that was my point
  93. # [12:15] <Hixie> you said that the ABNF said how to parse, right?
  94. # [12:15] <Hixie> and the ABNF says that that parses as type=text, subtype=html
  95. # [12:16] <julian> No, it doesn't
  96. # [12:16] <julian> The ABNF does not allow whitespace there
  97. # [12:16] <Hixie> the spec says that there is implied *LWS between all words
  98. # [12:17] <julian> I see I misread your example. I saw "text/plain ", but it was "text/ plain ".
  99. # [12:17] <julian> So no, that is invalid input
  100. # [12:18] <Hixie> ok see this is why we need a spec that actually says what it means and says how to parse things so we don't have to try to guess
  101. # [12:18] <julian> "The type, subtype, and parameter attribute names are case-insensitive. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name. Linear white space (LWS) MUST NOT be used between the type and subtype, nor between an attribute and its value. The presence or absence of a parameter might be significant to the processing of a media-type, depending...
  102. # [12:18] <julian> ...on its definition within the media type registry."
  103. # [12:18] <julian> So it says that.
  104. # [12:18] <Hixie> so you're saying that that sentence means the grammar is to be treated differently?
  105. # [12:19] <julian> "Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation of a field."
  106. # [12:19] <julian> It's all there.
  107. # [12:19] <Hixie> oh the authoring-level criteria there is what they meant by that?
  108. # [12:20] <julian> And yes, the way the ABNF work depends on out-of-band informaion. This is something we are fixing in httpbis.
  109. # [12:20] <julian> These are not "authoring-level criteria". It's regular spec text.
  110. # [12:20] <Hixie> could you please make it so (a) we don't have to read between the lines to work out how to parse things and (b) you define how to parse everything, valid or invalid?
  111. # [12:20] <julian> I think you are confusing yourself with that distinction you made up some time ago.
  112. # [12:21] <julian> (a) you don't need to read between the lines, just switch on common sense
  113. # [12:21] <Hixie> and i think you're making things worse by refusing to acknowledge the necessity of that deistinction
  114. # [12:22] <Hixie> distinction, even
  115. # [12:22] <julian> (b) the WG discussed this multiple times, and there's no consensus for doing so
  116. # [12:22] <julian> (need to run now)
  117. # [12:22] <Hixie> "switch on common sense" is "read between the lines" in the spec world
  118. # [12:24] <Hixie> because different people have different ideas of what is common sense
  119. # [12:25] <Hixie> for example, i think it's common sense that a format needs to apply Postel's law, instead of pushing that responsibility to user agents, where differences causes security bugs
  120. # [12:44] * Quits: annevk (opera@83.87.57.202) (Ping timeout)
  121. # [13:00] <hsivonen> julian: I think it's irresponsible not "insult the reader" and leave things undefined
  122. # [13:00] <hsivonen> s/not/not to/
  123. # [13:08] <Lachy> hsivonen, I think you mean 'I think it's irresponsible *to* "insult the reader"...' :-)
  124. # [13:11] <pimpbot> bugmail: [Bug 7549] define how to parse a MIME type <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Sep/0462.html>
  125. # [13:13] <hsivonen> Lachy: no, I mean it's irresponsible not to insult the reader given julian's take on what is an insult to the reader
  126. # [13:28] <Lachy> oh, sorry. I thought you were using a sane definition of insulting the reader.
  127. # [16:03] * Joins: tlr (tlr@128.30.52.169)
  128. # [16:40] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  129. # [17:32] * Joins: annevk (opera@83.87.57.202)
  130. # [19:19] * Quits: ChrisWilson (cwilso@131.107.0.104) (Ping timeout)
  131. # [19:24] * Joins: ChrisWilson (cwilso@131.107.0.85)
  132. # [19:26] * Quits: annevk (opera@83.87.57.202) (Quit: annevk)
  133. # [22:18] * Disconnected
  134. # Session Close: Sun Sep 20 00:00:00 2009

The end :)