HTML WG Teleconference

04 Sep 2008


See also: IRC log


AnneVK Cynthia_Shelly DanC HenriSivonen Joshue Julian Laura MikeSmith Shawn_Medero
SteveF, GezLemon, ChrisWilson, DaveSinger


Convene and review the agenda

MS: and ISSUE-55
... if we get through those we'll take a look at the tracker. Julian mentioned discussing the new void elements. Lets possibly add that
... Chris Wilson is not here so we skip ISSUE-20 and go straight to ISSUE-54

Issue 54

MS: regarding XSLT

<Julian> issue-54?

<trackbot> ISSUE-54 -- difficulties generating HTML5 from XSLT -- OPEN

<trackbot> http://www.w3.org/html/wg/tracker/issues/54

ISSUE-54 html5-from-xslt

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
... XSLT engines can't output <!DOCTYPE html>, but it is a conforming XML DOCTYPE.
... the proposal, is <!DOCTYPE html PUBLIC ""> or <!DOCTYPE html PUBLIC "some value">
... that would help with the XML case but is not valid [scribe: not sure if that was what said]
... I'm not sure the current text in the spec, <!DOCTYPE html PUBLIC "XSLT-compat"> makes sense, as it's not valid XML and might confuse people
... Any feedback on the current state of things?

<cshelly> having phone trouble, will lurk here

MS: Hixie added the "XSLT-compat" case to the spec, solely intended for XSLT tools
... not clear whether that's the best solution and if that helps people long term
... need to decide whether the change is ideal or whether we should go back to what we had before, just have <!doctype html>

JR: another option is to allow <!DOCTYPE html PUBLIC ""> or <!DOCTYPE html PUBLIC ''>

MS: that is another option certainly
... the reason Hixie didn't like that was that it looked "reasonable"
... he thinks it should look "unreasonable"

JR: whether it should look "unreasonable" has no consensus

<hsivonen> null and "" are distinct

JR: I look at it as having two ways to indicate there is no doctype

MS: Hixie thinks having that gives confusion; changing the meaning of the public ID might not be good
... it makes DOCTYPEs less purposeful [scribe: I hope I got that correct]

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

<DanC> (email seems to be working for this issue... though perhaps I'm not reading clearly enough to see communication breakdowns.)

JR: I'm open to make it simpler
... I think XSLT-compat is misleading and will also cause confusing

MS: none of us is going to say things not said on e-mail

HS: this is damned if you do, damned if you don't situation
... adding a DOCTYPE makes things confusing, not adding one makes XSLT people annoyed
... I'm happy to flip-flop on the empty string and use XSLT-compat to make it clear it's not for most people

MS: we'd only want people to use the long form if that's all their tool can

<hsivonen> (not really "happy")

DC: what do you mean with "we"?

<takkaria> 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

MS: I think most people want the spec to be simple and not provide options unless necessary

<hsivonen> takkaria, which browser?

MS: this might be a case where it is not necessary to add complication

<DanC> takkaria, is the interaction with quirks mode in email? I missed that. That seems more significant than aesthetic arguments.

<MikeSmith> takkaria: if you have data for that, please mail it to the list

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

HS: I don't think we should make it longer just for XSLT

<takkaria> (I thought it had already been mentioned on the list; has it not?)

(Also, some optional features of XSLT do allow <!doctype html>.)

<DanC> <takkaria> 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

<hsivonen> takkaria, my testing showed it was OK with modes

MS: I want to close this topic for now as there's no new information and not close to a resolution


<trackbot> ISSUE-55 -- head/@profile missing, but used in other specifications/formats -- RAISED

<trackbot> http://www.w3.org/html/wg/tracker/issues/55

Issue 55 (the profile attribute)

<head profile>

<DanC> editor's rationale from 6 May: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-May/014692.html

MS: <head profile> is not part of HTML5 and there hasn't been much new e-mail on this topic
... some new data on the case of making it conformant

<DanC> dissenting argument from 9 Jul 2007: http://lists.w3.org/Archives/Public/public-html/2007Jul/0571.html

(scribe hasn't seen data that suggests it was used in a conforming way)

MS: Some popular WordPress themes or plugins are generating <head profile>

[Can't be removed by a WordPress upgrade.]

MS: It seems there's not much support for re-adding profile to the HTML vocabulary

<Julian> +1 to DanC

DC: I think the cost is small and the benefit is to be seen; I said this before
... I'm waiting for a survey so I can formally object and we can move on

MS: I'll put the question to the group
... [explains various options for the survey]

DC: I think it's up for the chairs to determine whether the editor made all the considerations
... up to the chairs to say that a discussion is done

JR: I'd don't like to judge the editor, but the technical issue itself

MS: I think it's useful for people in the group to say whether or not they trust the editor
... it's not clear-cut who's right and we have to make some kind of decisions

<DanC> (I think the question should just be "shall HTML 5 have no profile attribute on the head element?")

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

<DanC> (no reason to continue/condone the "or worse" parts of the process)

JR: I don't think it's a good idea to conflate both issues as it might effect the outcome

MS: That's the point, we want to know why people say something

DC: I don't think that's possible
... if they don't give rationale, don't consider them

MS: I will talk about this with Chris and Dan as this is a process issue

<hsivonen> I'm in q

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
... 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.

MS: How do long do you think the discussion for the other attributes will take?

HS: I've no idea whether there's a satisfactory solution to that problem. (Category of conforming non-endorsed attributes.)

<DanC> (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.)

<DanC> (I'm also OK to have the issue closed for now and re-open it if new data comes up)

<Julian> (it would be good if the Microformats community would come up with an answer whether or not to @profile)

MS: I would like a decision
... anything else on profile? move on?

<DanC> (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 )

MS: we could go to the tracker agenda but I don't see anything urgent
... we could talk about void elements

new void elements

(<script></script> is an empty element, which would be a confusing term to use therefore)

<hsivonen> Julian, it would be nice if microformats had a specced processing model and conformance reqs

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
... Users of HTML have no information on whether an element is a void element.
... 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

<Zakim> DanC, you wanted to ask for pointers to earlier discussion of void elements

DC: I find it hard to believe that since 2004 this hasn't already come up

AvK: and also for authors, in terms of backwards compatibility

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.
... Just make enough HTML libraries and problem solved.
... 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.
... These void elements also don't come up all the time. There's been a ten year break or so...
... 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

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.
... I'm totally sure that eg <eventsource></eventsource> will turn up in the real Web

DC: The spec already deals with every input stream, right?

<DanC> (I think whether it's void or not is a pretty small part of the design of new elements)

HS: the spec covers parsing yes, but eg. <command></command> is non-conforming for text/html

<Zakim> MikeSmith^, you wanted to mention cost of adding support for new void elements to libraries and other tools

JR: If there's no technical problem it's just believe

<Laura> Steve and Gez have conficting meetings. Sends regrets.

AvK: it gives confusion with <br>, where <br></br> does different things, authors will get confused because they think they can put stuff inside, updating a fixed list is small

JR: the problem is to deploy those libraries

MS: those elements are not supported currently, so it will take some time anyway

HS: two void elements XSLT doesn't deal with are already widely deployed, <embed> and to lesser extent <source>
... the question is whether we should introduce new void elements in HTML5
... should we have <command>command-type</command> and <eventsource></eventsource> instead?

<deane> anne: I think allowing <command></command> and <eventsource></eventsource> would be a bad move

HS: so the question is whether the HTML5 spec is the last spec to introduce new void elements (<source> and <embed>), or will we have new elements?

deane, I'm the scribe

<Julian> +1 to henri

<hsivonen> <p>foo<aside> will hurt authors more likely

It would be interesting to see in a few years whether <source> has been a problem.

Then we can decide for HTML6 whether it was worth it

MS: [scribe missed a lot]
... So we will have a meeting next week, same time. Chris Wilson chairing.
... If anybody would like to volunteer to scribe for that meeting, speak up

DC: I'm probably available

MS: CW will be sending a detailed agenda
... adjourn

Summary of Action Items