15:58:07 RRSAgent has joined #html-wg 15:58:07 logging to http://www.w3.org/2008/09/04-html-wg-irc 15:58:09 RRSAgent, make logs public 15:58:09 Zakim has joined #html-wg 15:58:11 Zakim, this will be HTML 15:58:11 ok, trackbot; I see HTML_WG()12:00PM scheduled to start in 2 minutes 15:58:12 Meeting: HTML Issue Tracking Teleconference 15:58:12 Date: 04 September 2008 15:59:14 HTML_WG()12:00PM has now started 15:59:21 + +2 15:59:29 zakim, +2 is Joshue 15:59:29 +Joshue; got it 15:59:30 Zakim, call Mike-Mobile 15:59:30 ok, MikeSmith; the call is being made 15:59:31 +Mike 15:59:40 +Laura 16:00:05 Zakim, who's on the phone? 16:00:05 On the phone I see Joshue, Mike, Laura 16:00:58 Agenda: http://www.w3.org/mid/20080903224031.GA8044@toro.w3.mag.keio.ac.jp 16:01:33 + +1.425.467.aabb 16:01:34 +Julian 16:01:48 Zakim, who's on the phone? 16:01:48 On the phone I see Joshue, Mike, Laura, +1.425.467.aabb, Julian 16:01:51 Zakim, aabb is me 16:01:51 +smedero; got it 16:02:01 +??P16 16:02:21 Zakim, P16 is me 16:02:21 sorry, hsivonen, I do not recognize a party named 'P16' 16:02:48 Zakim, ??P16 is hsivonen 16:02:48 +hsivonen; got it 16:02:59 +DanC 16:03:13 smedero has left #html-wg 16:03:28 smedero has joined #html-wg 16:04:02 zakim, mute me 16:04:02 Joshue should now be muted 16:04:23 Zakim, passcode? 16:04:23 the conference code is 4865 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), anne 16:04:32 +??P22 16:04:44 Zakim, ??P22 is me 16:04:47 +anne; got it 16:04:57 Zakim, who is on the phone? 16:04:57 On the phone I see Joshue (muted), Mike, Laura, smedero, Julian, hsivonen, DanC, anne 16:05:23 Zakim, pick a scribe 16:05:23 Not knowing who is chairing or who scribed recently, I propose Mike 16:05:32 scribe: anne 16:05:39 scribenick: anne 16:06:00 Topic: Convene and review the agenda 16:06:11 issue-20? 16:06:11 ISSUE-20 -- Improvements to the table-headers algorithm in the HTML 5 spec -- OPEN 16:06:11 http://www.w3.org/html/wg/tracker/issues/20 16:06:13 MS: ISSUE-20 is on the agenda 16:06:28 issue-54? 16:06:28 ISSUE-54 -- difficulties generating HTML5 from XSLT -- OPEN 16:06:28 http://www.w3.org/html/wg/tracker/issues/54 16:06:37 MS: ISSUE-54 is also on the agenda 16:06:44 issue-55? 16:06:45 ISSUE-55 -- head/@profile missing, but used in other specifications/formats -- RAISED 16:06:45 http://www.w3.org/html/wg/tracker/issues/55 16:06:51 MS: and ISSUE-55 16:07:38 MS: if we get through those we'll take a look at the tracker. Julian mentioned discussing the new void elements. Lets possibly add that 16:07:55 MS: Chris Wilson is not here so we skip ISSUE-20 and go straight to ISSUE-54 16:08:01 Topic: Issue 54 16:08:04 MS: regarding XSLT 16:08:17 issue-54? 16:08:17 ISSUE-54 -- difficulties generating HTML5 from XSLT -- OPEN 16:08:17 http://www.w3.org/html/wg/tracker/issues/54 16:08:22 Topic: ISSUE-54 html5-from-xslt 16:08:49 MS: what change should be made to the restrictions on the DOCTYPE in HTML5 to make it possible for existing XSLT engines to output conforming HTML5 16:10:03 MS: XSLT engines can't output , but it is a conforming XML DOCTYPE. 16:10:46 MS: the proposal, is or 16:11:13 MS: that would help with the XML case but is not valid [scribe: not sure if that was what said] 16:11:46 MS: I'm not sure the current text in the spec, makes sense, as it's not valid XML and might confuse people 16:11:57 q? 16:12:02 DanC has joined #html-wg 16:12:04 cshelly has joined #html-wg 16:12:44 MS: Any feedback on the current state of things? 16:12:44 having phone trouble, will lurk here 16:13:07 MS: Hixie added the "XSLT-compat" case to the spec, solely intended for XSLT tools 16:13:17 -Mike 16:13:24 MS: not clear whether that's the best solution and if that helps people long term 16:13:29 Zakim, call Mike-Mobile 16:13:29 ok, MikeSmith; the call is being made 16:13:31 +Mike 16:14:24 MS: need to decide whether the change is ideal or whether we should go back to what we had before, just have 16:14:24 q+ 16:14:29 ack Julian 16:14:36 +Cynthia_Shelly 16:14:46 JR: another option is to allow or 16:14:51 MS: that is another option certainly 16:15:07 MS: the reason Hixie didn't like that was that it looked "reasonable" 16:15:17 MS: he thinks it should look "unreasonable" 16:15:48 JR: whether it should look "unreasonable" has no consensus 16:16:00 null and "" are distinct 16:16:11 JR: I look at it as having two ways to indicate there is no doctype 16:17:34 MS: Hixie thinks having that gives confusion; changing the meaning of the public ID might not be good 16:17:43 -Cynthia_Shelly 16:18:02 MS: it makes DOCTYPEs less purposeful [scribe: I hope I got that correct] 16:18:21 +Cynthia_Shelly 16:18:30 JR: I don't really care whether we make it a real public ID in the historical way; I would expect there to be pushback 16:18:43 (email seems to be working for this issue... though perhaps I'm not reading clearly enough to see communication breakdowns.) 16:18:44 JR: I'm open to make it simpler 16:18:57 q+ 16:19:05 JR: I think XSLT-compat is misleading and will also cause confusing 16:19:17 ack hsivonen 16:19:18 MS: none of us is going to say things not said on e-mail 16:19:38 HS: this is damned if you do, damned if you don't situation 16:19:56 MS: adding a DOCTYPE makes things confusing, not adding one makes XSLT people annoyed 16:20:02 s/MS:/HS:/ 16:20:33 HS: I'm happy to flip-flop on the empty string and use XSLT-compat to make it clear it's not for most people 16:21:07 MS: we'd only want people to use the long form if that's all their tool can 16:21:14 (not really "happy") 16:21:18 DC: what do you mean with "we"? 16:21:30 I think there's a really big problem with allowing 'public ""' in the doctype; it interacts badly with quirks mode. if xslt people want to write standards-mode content, they're better off fixing the output mode than outputting quirky content 16:21:46 MS: I think most people want the spec to be simple and not provide options unless necessary 16:21:51 q+ 16:21:57 ack Julian 16:21:57 takkaria, which browser? 16:21:58 MS: this might be a case where it is not necessary to add complication 16:22:18 q+ 16:22:19 takkaria, is the interaction with quirks mode in email? I missed that. That seems more significant than aesthetic arguments. 16:22:22 takkaria: if you have data for that, please mail it to the list 16:22:25 q+ 16:22:28 ack hsivonen 16:22:38 JR: If the goal is to have one notation for the DOCTYPE and another goal is to allow XSLT to generate HTML5 we could pick the longer 16:22:50 q? 16:22:58 ack DanC 16:23:02 HS: I don't think we should make it longer just for XSLT 16:23:14 (I thought it had already been mentioned on the list; has it not?) 16:23:21 (Also, some optional features of XSLT do allow .) 16:23:48 I think there's a really big problem with allowing 'public ""' in the doctype; it interacts badly with quirks mode. if xslt people want to write standards-mode content, they're better off fixing the output mode than outputting quirky content 16:23:51 takkaria, my testing showed it was OK with modes 16:24:58 MS: I want to close this topic for now as there's no new information and not close to a resolution 16:25:13 issue-55? 16:25:13 ISSUE-55 -- head/@profile missing, but used in other specifications/formats -- RAISED 16:25:13 http://www.w3.org/html/wg/tracker/issues/55 16:25:16 Topic: Issue 55 (the profile attribute) 16:25:18 Topic: 16:25:44 editor's rationale from 6 May: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-May/014692.html 16:25:58 MS: is not part of HTML5 and there hasn't been much new e-mail on this topic 16:26:08 MS: some new data on the case of making it conformant 16:26:16 dissenting argument from 9 Jul 2007: http://lists.w3.org/Archives/Public/public-html/2007Jul/0571.html 16:26:21 (scribe hasn't seen data that suggests it was used in a conforming way) 16:26:59 MS: Some popular WordPress themes or plugins are generating 16:27:21 [Can't be removed by a WordPress upgrade.] 16:27:58 MS: It seems there's not much support for re-adding profile to the HTML vocabulary 16:28:03 q? 16:28:15 +1 to DanC 16:28:20 DC: I think the cost is small and the benefit is to be seen; I said this before 16:28:41 DC: I'm waiting for a survey so I can formally object and we can move on 16:28:58 MS: I'll put the question to the group 16:29:42 q+ 16:29:52 ack Julian 16:29:57 MS: [explains various options for the survey] 16:30:11 q+ 16:30:18 DC: I think it's up for the chairs to determine whether the editor made all the considerations 16:30:22 ack Julian 16:30:27 DC: up to the chairs to say that a discussion is done 16:30:49 JR: I'd don't like to judge the editor, but the technical issue itself 16:31:23 MS: I think it's useful for people in the group to say whether or not they trust the editor 16:32:19 MS: it's not clear-cut who's right and we have to make some kind of decisions 16:32:27 q+ 16:32:29 (I think the question should just be "shall HTML 5 have no profile attribute on the head element?") 16:32:51 MS: in most WGs it's the chairs, but for better or worse a lot of the decisions of things in the spec now have been made 16:33:13 (no reason to continue/condone the "or worse" parts of the process) 16:33:25 JR: I don't think it's a good idea to conflate both issues as it might effect the outcome 16:34:00 MS: That's the point, we want to know why people say something 16:34:17 DC: I don't think that's possible 16:34:28 DC: if they don't give rationale, don't consider them 16:34:35 deane has joined #html-wg 16:34:41 MS: I will talk about this with Chris and Dan as this is a process issue 16:35:18 I'm in q 16:35:33 ack hsivonen 16:35:40 MikeSmith^ has joined #html-wg 16:36:17 HS: I'd prefer to defer the question on profile until after we've considered a way to have a category of attributes not to recommend to authors of new documents but not forbid 16:36:37 q+ 16:36:41 q? 16:36:58 HS: allowing it in the validator is easy, but there's a complexity cost for authors. Microformats authors might care for it, but then consumers don't, etc. 16:37:53 MS: How do long do you think the discussion for the other attributes will take? 16:38:20 HS: I've no idea whether there's a satisfactory solution to that problem. (Category of conforming non-endorsed attributes.) 16:38:26 (I suppose it's OK with me to move the profile attribute back to "raised" while the discussion of not-very-nice attributes; the recent data HS collected certainly makes me wonder about various things.) 16:38:42 q- 16:38:45 (I'm also OK to have the issue closed for now and re-open it if new data comes up) 16:38:50 q? 16:38:59 adele has joined #html-wg 16:39:09 (it would be good if the Microformats community would come up with an answer whether or not to @profile) 16:39:17 MS: I would like a decision 16:39:56 q? 16:40:05 MS: anything else on profile? move on? 16:40:22 (I recently checked in #microformats and didn't find much support for @profile; cf http://www.w3.org/QA/2008/08/the_details_of_data_in_documen.html ) 16:40:33 MS: we could go to the tracker agenda but I don't see anything urgent 16:40:43 MS: we could talk about void elements 16:40:46 Topic: new void elements 16:41:06 q+ 16:41:08 ( is an empty element, which would be a confusing term to use therefore) 16:41:10 ack Julian 16:41:18 Zakim, who makes noise? 16:41:18 I don't understand your question, anne. 16:41:40 Julian, it would be nice if microformats had a specced processing model and conformance reqs 16:42:08 Zakim, mute me 16:42:08 smedero should now be muted 16:42:20 JR: Even if we did the DOCTYPE thing for XSLT, they still wouldn't do the new elements; they also wouldn't do SVG and MathML 16:42:23 q+ 16:42:45 q+ to ask for pointers to earlier discussion of void elements 16:43:14 JR: Users of HTML have no information on whether an element is a void element. 16:43:32 -smedero 16:43:39 q+ 16:43:51 JR: Having a fixed set of void elements from HTML4 was nice, but now all those sets over the Web need to be updated. Would like to have a story that also works for HTML5+n 16:43:52 ack DanC 16:43:52 DanC, you wanted to ask for pointers to earlier discussion of void elements 16:44:07 DC: I find it hard to believe that since 2004 this hasn't already come up 16:44:13 +Shawn_Medero 16:44:47 anne: I don't have pointers, but was seen as a minor issue by browsers at least 16:45:10 q? 16:45:13 AvK: and also for authors, in terms of backwards compatibility 16:45:34 ack hsivonen 16:46:07 HS: I had considered this issue before but I didn't see it as a big deal. I would write a serializer with a liberal license that other people then can use. 16:46:19 HS: Just make enough HTML libraries and problem solved. 16:46:55 q+ 16:47:16 HS: I thought everyone would bring their own serializer. I can see a problem here, but I don't think it's as big as JR makes it seem. 16:47:28 dbaron has joined #html-wg 16:47:31 HS: These void elements also don't come up all the time. There's been a ten year break or so... 16:47:47 q+ to mention cost of adding support for new void elements to libraries and other tools 16:48:22 HS: I can see how the implied paragraph end tag and void elements is in theory bad, but I'm not sure if it's really a problem in practice 16:48:31 ack Julian 16:49:24 JR: I assume HSs' serializer also has a hardwired set of elements. Whatever seralizer you take it will generate a start and end tag and user agents will have to deal with it. 16:49:43 JR: I'm totally sure that eg will turn up in the real Web 16:50:10 DC: The spec already deals with every input stream, right? 16:50:17 (I think whether it's void or not is a pretty small part of the design of new elements) 16:50:30 HS: the spec covers parsing yes, but eg. is non-conforming for text/html 16:51:01 ack MikeSmith^ 16:51:01 MikeSmith^, you wanted to mention cost of adding support for new void elements to libraries and other tools 16:51:33 JR: If there's no technical problem it's just believe 16:51:58 q+ 16:52:04 Steve and Gez have conficting meetings. Sends regrets. 16:52:31 regrets+ SteveF 16:52:38 regrets+ GezLemon 16:53:01 AvK: it gives confusion with
, where

does different things, authors will get confused because they think they can put stuff inside, updating a fixed list is small 16:53:24 JR: the problem is to deploy those libraries 16:54:09 ack hsivonen 16:54:17 MS: those elements are not supported currently, so it will take some time anyway 16:54:45 HS: two void elements XSLT doesn't deal with are already widely deployed, and to lesser extent 16:55:18 HS: the question is whether we should introduce new void elements in HTML5 16:55:37 HS: should we have command-type and instead? 16:55:58 anne: I think allowing and would be a bad move 16:56:07 HS: so the question is whether the HTML5 spec is the last spec to introduce new void elements ( and ), or will we have new elements? 16:56:17 deane, I'm the scribe 16:56:18 +1 to henri 16:56:37 q? 16:57:35

foo