{minutes} HTML WG telcon 2008-09-04 - html5&xslt, @profile, void elements

The HTML Working Group will had its weekly teleconference on
2008-09-04 for 60 minutes from 16:00Z 17:00Z.

An HTML version of the minutes are available at:


          AnneVK Cynthia_Shelly DanC HenriSivonen Joshue Julian Laura
          MikeSmith Shawn_Medero

          SteveF, GezLemon, ChrisWilson, DaveSinger




     * Topics
         1. Convene and review the agenda
         2. ISSUE-54 html5-from-xslt
         3. <head profile>
         4. new void elements

     * Summary of Action Items

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

   MS: regarding XSLT

   <Julian> issue-54?

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

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

   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

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


   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:


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

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

   [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

   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

   <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

   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

   <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

   <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


   MS: we could go to the tracker agenda but I don't see anything
   ... 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
   ... 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
   ... 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

[end of minutes]

Received on Thursday, 4 September 2008 17:23:14 UTC