See also: IRC log
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 -- OPEN
<trackbot> http://www.w3.org/html/wg/tracker/issues/54
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
issue-55?
<trackbot> ISSUE-55 -- head/@profile missing, but used in other specifications/formats -- RAISED
<trackbot> http://www.w3.org/html/wg/tracker/issues/55
<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
(<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