W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > June 2008

[Bug 5752] Parsing should be specified for future updates

From: <bugzilla@wiggum.w3.org>
Date: Sun, 15 Jun 2008 18:20:57 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1K7wqX-0001RO-F8@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5752





--- Comment #14 from Lachlan Hunt <lachlan.hunt@lachy.id.au>  2008-06-15 18:20:57 ---
If we make the trailing slash close unknown elements, then we'll be likely to
end up with a potentially very confusing situation in the future, where the
slash means either:

1. Non-conforming and meaningless as in the case of existing non-empty
elements.
2. Conforming, but meaningless syntactic sugar that can be used on existing
void elements.
3. Conforming empty element indicator on currently unknown, future void
elements
4. Empty element indicator on non-empty elements defined in the future (may or
may not be considered conforming).

For #1, there are lots of authors that use <p/>, <div/>, etc. in existing
pages, some of which still rely on the element's not being closed. For
compatibility reasons, this cannot be changed.

For #2, <br/>, <meta/>, etc. are widely used. But it's meaningless because the
element is empty with or without the slash.

For #3, in the future, newly defined void elements would require the slash in
order to be treated as empty in the then current browsers. As newer browsers
are released with support for these elements, they'll gradually move into
category #2.

For #4, dealing with newly introduced non-empty elements is the biggest
problem.  Say, for example, a <foo>...</foo> element is introduced in the
future.  Before it's implemented, the then current browsers would handle it as
an unknown element and thus treat <foo/> as being empty.  But when it is
implemented and is thus an unknown element, do those implementations retain the
meaning of the slash, or put these elements into category #1, where the slash
is meaningless?

By retaining the meaning of the slash, then we end up with a situation where it
is meaningless on some non-empty elements and meaningful on others, and authors
would just have to know which. But the question of whether or not it would be
conforming still remains.  By not retaining its meaning, we could potentially
end up with a situation authors have come to depend on it being meaningful and
then suddenly find that it breaks in the newer browsers that support support
the new non-empty element.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 15 June 2008 18:21:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 15 June 2008 18:21:32 GMT