Once upon a time Ian Hickson shaped the electrons to say...
> On Wed, 6 Dec 2006, Simon Pieters wrote:
> > From: Ian Hickson <[EMAIL PROTECTED]>
> > > Hm. Actually an start tag has to imply an end tag
> > > for compatibility with browsers... spec fixed.
> > Then nested optgroups as allowed in WF2
On Wed, 6 Dec 2006, Henri Sivonen wrote:
>
> Side note:
> I considered the inference of a tbody harmless enough that the validation mode
> I describe as the text/html-compatible subset of XHTML5 allows tr as child of
> table when applied to XML.
>
> Is this a bad idea? I thought it wasn't particu
On Wed, 6 Dec 2006, Bjoern Hoehrmann wrote:
>
> * Ian Hickson wrote:
> >No conformance criteria are broken if the user agent is assumed to have
> >"converted" the document to a serialisable form by adding an appropriate
> > element and then serialised that.
>
> >If the user agent has not, e.g. i
On Wed, 6 Dec 2006, Simon Pieters wrote:
>
> From: Ian Hickson <[EMAIL PROTECTED]>
> > Hm. Actually an start tag has to imply an end tag
> > for compatibility with browsers... spec fixed.
>
> Then nested optgroups as allowed in WF2 is just another thing that only
> works in XHTML5? How many si
On Dec 6, 2006, at 23:18, Bjoern Hoehrmann wrote:
What you probably mean is when the authoring tool makes claims
about the
contents of the generated file. If it claims that the file contains a
table element with tr child elements then it would be misbehaving, but
not because table elements mus
* Ian Hickson wrote:
>No conformance criteria are broken if the user agent is assumed to have
>"converted" the document to a serialisable form by adding an appropriate
> element and then serialised that.
>If the user agent has not, e.g. it shows a tree of what it thinks it
>serialised, and that
Hi,
From: Ian Hickson <[EMAIL PROTECTED]>
Hm. Actually an start tag has to imply an end tag
for compatibility with browsers... spec fixed.
Then nested optgroups as allowed in WF2 is just another thing that only
works in XHTML5? How many sites would break if wasn't implied
here?
Regards,
On Wed, 6 Dec 2006, Bjoern Hoehrmann wrote:
>
> So my authoring tool takes a conforming document, parses that into a
> Document, the user adds a proper table with only tr/td elements, and
> requests to save the document as HTML. My authoring tool then writes
> Document.innerHTML into the file.
* Ian Hickson wrote:
>No, he doesn't. The spec explicitly says of the 9.1 section that "it does
>not apply to conformance checkers; conformance checkers must use the
>requirements given in the next section ("parsing HTML documents")". (Just
>added; the spec said something equivalent before but i
On Wed, 6 Dec 2006, Simon Pieters wrote:
>
> From: Ian Hickson <[EMAIL PROTECTED]>
> > > A missing implies non-conformance but no parse error per 9.1
> > > and 9.2 respectively.
> >
> > and other form controls aren't yet really part of the
> > specification, and are missing all over the place.
Hi,
From: Ian Hickson <[EMAIL PROTECTED]>
> A missing implies non-conformance but no parse error per 9.1
> and 9.2 respectively.
and other form controls aren't yet really part of the
specification, and are missing all over the place. I added these to the
syntax section for you, [...]
FWIW..
On Wed, 6 Dec 2006, Bjoern Hoehrmann wrote:
>
> If something can be deduced it "is there" for all intents and purposes.
> You can look at this from a very practical perspective: someone wants to
> build a "HTML5" "conformance checker". He has already implemented an al-
> gorithm that transforms
* Ian Hickson wrote:
>I agree that the requirements could be deduced. But unless they are
>actually there, they aren't actually there. If you see what I mean.
If something can be deduced it "is there" for all intents and purposes.
You can look at this from a very practical perspective: someone wa
On Tue, 5 Dec 2006, Bjoern Hoehrmann wrote:
>
> * Ian Hickson wrote:
>> No, it doesn't. It doesn't define the syntax at all. It defines how to
>> parse the syntax, and what to report as a syntax error, but that
>> section has no normative criteria that apply to documents.
>
> That is quite irrel
* Ian Hickson wrote:
>No, it doesn't. It doesn't define the syntax at all. It defines how to
>parse the syntax, and what to report as a syntax error, but that section
>has no normative criteria that apply to documents.
That is quite irrelevant. The definition of the parsing algorithm
along with
Bjoern Hoehrmann wrote:
I may be able to make additional suggestions once someone showed me
an example of HTML syntax where a 'p' element has a 'pre' child
element.
The pre element is allowed to occur where structured inline-level
elements are allowed.
http://www.whatwg.org/specs/web-apps/c
On Tue, 5 Dec 2006, Bjoern Hoehrmann wrote:
>
> [...] section 9.2 defines syntax and parsing rules together.
No, it doesn't. It doesn't define the syntax at all. It defines how to
parse the syntax, and what to report as a syntax error, but that section
has no normative criteria that apply to do
* Ian Hickson wrote:
>How do you propose to organise it instead? The XML, HTML, and CSS
>specifications quite clearly show that organising it so that the syntax
>and the parsing rules are defined in the same prose leads to serious
>deficiences (HTML forgot to define parsing altogether, CSS faile
On Mon, 4 Dec 2006, Bjoern Hoehrmann wrote:
>
> * Ian Hickson wrote:
> >> You should request removal of the section. It is just a non-normative
> >> discussion of implications of the parsing algorithm despite the claim
> >> that "extra restrictions" are being defined and the misuse of RFC2119
> >>
* Ian Hickson wrote:
>> You should request removal of the section. It is just a non-normative
>> discussion of implications of the parsing algorithm despite the claim
>> that "extra restrictions" are being defined and the misuse of RFC2119
>> keywords. As the thread shows, such discussion is unlike
On Mon, 4 Dec 2006, Simon Pieters wrote:
>
> But the HTML syntax section doesn't apply to XHTML5.
On Mon, 4 Dec 2006, Lachlan Hunt wrote:
>
> I was referring to HTML5, not XHTML5. Like how in that section linked above
> it places an additional restriction on the p element:
>
> | A p element mus
* Lachlan Hunt wrote:
> The spec should mention the additional restriction that table
>elements cannot contain child tr elements, because they imply the tbody
>element in such cases.
>
>http://www.whatwg.org/specs/web-apps/current-work/#restrictions
U+0059 LATIN CAPITAL LETTER Y
U+006F LATIN S
Ian Hickson wrote:
On Mon, 4 Dec 2006, Lachlan Hunt wrote:
The spec should mention the additional restriction that table elements
cannot contain child tr elements, because they imply the tbody element
in such cases.
http://www.whatwg.org/specs/web-apps/current-work/#restrictions
On Sun, 3
On Mon, 4 Dec 2006, Lachlan Hunt wrote:
>
> The spec should mention the additional restriction that table elements
> cannot contain child tr elements, because they imply the tbody element
> in such cases.
>
> http://www.whatwg.org/specs/web-apps/current-work/#restrictions
On Sun, 3 Dec 2006,
On Dec 3, 2006, at 20:33, Lachlan Hunt wrote:
The spec should mention the additional restriction that table
elements cannot contain child tr elements, because they imply the
tbody element in such cases.
Not in XHTML5.
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
Hi,
The spec should mention the additional restriction that table
elements cannot contain child tr elements, because they imply the tbody
element in such cases.
http://www.whatwg.org/specs/web-apps/current-work/#restrictions
--
Lachlan Hunt
http://lachy.id.au/
26 matches
Mail list logo
