- From: Michael(tm) Smith <mike@w3.org>
- Date: Fri, 5 Sep 2008 02:22:37 +0900
- To: public-html-wg-announce@w3.org
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:
http://www.w3.org/2008/09/04-html-wg-minutes.html
Present
AnneVK Cynthia_Shelly DanC HenriSivonen Joshue Julian Laura
MikeSmith Shawn_Medero
Regrets
SteveF, GezLemon, ChrisWilson, DaveSinger
Chair
MikeSmith
Scribe
anne
Contents
* 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
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
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
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
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/014
692.html
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.htm
l
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
)
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
[end of minutes]
Received on Thursday, 4 September 2008 17:23:14 UTC