On Sun, 28 Aug 2011, Bronislav Klu�~Mka wrote:
Hi,
HTML5 defines several void elements.
I think this enumeration is insufficient, and I'd like to suggest to simply
allow every element to have syntax with / at the end if such element has no
content.
e.g
div class=placeholder /
script
On Sun, 28 Aug 2011 19:45:50 +0200, Jukka K. Korpela jkorp...@cs.tut.fi
wrote:
28.8.2011 17:52, Aryeh Gregor wrote:
Void is correct:
http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#void-elements
I see. What a pointless and confusing change (from HTML tradition and
29.8.2011 13:10, Simon Pieters wrote:
In which way is void better than empty?
The sentence p/p is an empty element since it has no content, but p
is not an empty element. is more confusing.
More confusing than what? (Is that hypothetical sentence more confusing
than p/p is a void element
On Mon, 29 Aug 2011 12:17:29 +0200, Jukka K. Korpela jkorp...@cs.tut.fi
wrote:
29.8.2011 13:10, Simon Pieters wrote:
In which way is void better than empty?
The sentence p/p is an empty element since it has no content, but p
is not an empty element. is more confusing.
More confusing
On 29.8.2011 12:17, Jukka K. Korpela wrote:
29.8.2011 13:10, Simon Pieters wrote:
In which way is void better than empty?
The sentence p/p is an empty element since it has no content, but p
is not an empty element. is more confusing.
More confusing than what? (Is that hypothetical
On Sun, Aug 28, 2011 at 12:26 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
The word void, though used even in the validator's message, is at least
misleading if not incorrect. The correct word is empty.
Void is correct:
28.8.2011 17:52, Aryeh Gregor wrote:
Void is correct:
http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#void-elements
I see. What a pointless and confusing change (from HTML tradition and
SGML usage). Empty is descriptive (an element that has no content, or
has empty
Hi,
HTML5 defines several void elements.
I think this enumeration is insufficient, and I'd like to suggest to
simply allow every element to have syntax with / at the end if such
element has no content.
e.g
div class=placeholder /
script src=lib.js /
Brona Klucka
Bronislav Klučka bronislav.klu...@bauglir.com schrieb am Sun, 28 Aug
2011 01:56:15 +0200:
HTML5 defines several void elements.
I think this enumeration is insufficient, and I'd like to suggest to
simply allow every element to have syntax with / at the end if such
element has no content.
28.8.2011 3:10, Nils Dagsson Moskopp wrote:
Bronislav Klučka bronislav.klu...@bauglir.com schrieb am Sun, 28 Aug
2011 01:56:15 +0200:
HTML5 defines several void elements.
I think this enumeration is insufficient, and I'd like to suggest to
simply allow every element to have syntax with / at
On Feb 15, 2006, at 4:41 PM, Ian Hickson wrote:We're stuck with it forever as well, since most of the Dashboard widgets use script src=""/ in HTML. You can say we're wrong in the spec, but we won't be able to change it. :(I think we need a dashboard mode, given that this is incompatible with all
On Thu, 16 Feb 2006 21:02:16 +0100, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 16 Feb 2006, Tim Altman wrote:
OK. Assuming the HTML5 document is served with a text/html doctype,
how would
the following markup be parsed?
table
tr
td
canvas/
pFoo/p
/td
/tr
/table
Hi,
From: David Hyatt [EMAIL PROTECTED]
Also, script src=.../ is actually supported even in HTML by Firefox
and Safari.
I think they do a reparse when they hit EOF if they're in script parsing
mode. That should probably be abadoned for the same reason as comments
shouldn't be reparsed.
On Thu, 16 Feb 2006, Tim Altman wrote:
OK. Assuming the HTML5 document is served with a text/html doctype, how would
the following markup be parsed?
table
tr
td
canvas/
pFoo/p
/td
/tr
/table
You omitted the DOCTYPE, which makes it a difficult parse error and
On Wed, 15 Feb 2006, Tim Altman wrote:
May OBJECT and CANVAS be treated as empty elements, i.e. canvas / and
object / if there is no fallback content?
I don't understand your question.
If you mean Can the string 'object/' be treated as an empty element
tag, the answer is no.
If you mean
On Thu, 16 Feb 2006 00:49:15 +0100, Lachlan Hunt
[EMAIL PROTECTED] wrote:
Tim Altman wrote:
On Wed, 15 Feb 2006 23:48:57 +0100, Ian Hickson [EMAIL PROTECTED] wrote:
On Wed, 15 Feb 2006, Tim Altman wrote:
May OBJECT and CANVAS be treated as empty elements, i.e. canvas /
and
object / if
On Wed, 15 Feb 2006, Michael Enright wrote:
What about 'foo /' with a space between 'o' and '/' ? There are many
legacy pages with that kind of mark-up on br elements and so forth.
There are also lot of legacy pages that do it on things like p, sadly.
On br it's harmless, and it doesn't help
BTW, not sure if you have this in the WhatWG parsing spec, but a
stray /p (that does not match some opening p) has to be treated
like an open p.
Also, script src=.../ is actually supported even in HTML by
Firefox and Safari. We're stuck with it forever as well, since most
of the
On Wed, 15 Feb 2006, David Hyatt wrote:
BTW, not sure if you have this in the WhatWG parsing spec, but a stray
/p (that does not match some opening p) has to be treated like an
open p.
It's listed as something that we might want to consider if we spec quirks
mode. I'm considering just
David Hyatt wrote:
Also, script src=.../ is actually supported even in HTML by
Firefox and Safari.
Firefox trunk builds do not support unclosed script tags (bug 305873).
Gavin
David Hyatt wrote:
Also, script src=.../ is actually supported even in HTML by
Firefox and Safari. We're stuck with it forever as well, since most of
This was a bug in the logic that determined whether or not we'd run
scripts. To test this add another inline script (at least one with a
21 matches
Mail list logo