On Fri, 27 Jan 2006, Alexey Feldgendler wrote:
>
> 1. What happens with the following:
On Fri, 27 Jan 2006, Henri Sivonen wrote:
> >
> > That wouldn't work. You can't know whether something is well-formed or
> > not til you get to the end of it.
>
> I was not suggesting anything that needs observation to the end of the
> document. The whole point was that decisions could be made
On Jan 27, 2006, at 01:17, Ian Hickson wrote:
On Wed, 25 Jan 2006, Henri Sivonen wrote:
These events don't go to the DOM builder / content sink directly.
Instead, there's a filter layer that takes care of tag inference and
emits a well-formed event stream (TagInferenceFilter.java and
EmptyEleme
On Fri, 27 Jan 2006 08:08:49 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:
Ok, I specced out what I think is a workable algorithm that works a lot
better than what we had before.
It still only supports and elements inside for now, but
at least it does so in a way compatible with Safari and
Ok, I specced out what I think is a workable algorithm that works a lot
better than what we had before.
It still only supports and elements inside for now, but at
least it does so in a way compatible with Safari and Mozilla's DOMs, and
compatible with Opera and IE's renderings.
http://w
Alexey Feldgendler wrote:
On Thu, 26 Jan 2006 21:09:44 +0600, Anne van Kesteren
<[EMAIL PROTECTED]> wrote:
has never been defined in a way that it could give entire paragraphs
emphasis. I'm not really saying anything is wrong about it, just that
has never been defined. Also, was defined to be
On Wed, 25 Jan 2006, Henri Sivonen wrote:
>
> Anyway, here's what I thought they were doing:
>
> There's low-level parser [that] is kind of like a tag-level lexer and
> emits a (non-well-formed) sequence of SAX-like events like startTag,
> characters, endTag and comment (in my parser* HtmlParse
On Thu, 26 Jan 2006, Lachlan Hunt wrote:
>
> Also, it may need some more improvement, I found an incredibly insane
> condition that fails in Safari and another that fails a little in
> Mozilla.
>
>
> XYZ
>
> Mozilla:
> BODY
> + EM
> + P
> + SPAN
> + H1
> + EM
>
On Thu, 26 Jan 2006, Mikko Rantalainen wrote:
>
> I think a simple way to parse what the author meant is to use just the
> following rules:
>
> 1) An opening tag always starts a new element
> 2) A matching closing tag closes the element
> 3) A non-matching closing tag (top of the element stack
>
Anything the WHATWG specifies in this area must be largely compatible
with WinIE. If you specify error recovery that would yield
dramatically different results, then nobody is going to implement
it. Safari's algorithm is designed to keep a relatively sane DOM, to
keep the performance snap
On Thu, Jan 26, 2006 at 06:15:06AM +0600, Alexey Feldgendler wrote:
> On Thu, 26 Jan 2006 03:14:07 +0600, Mike Hoye <[EMAIL PROTECTED]>
> wrote:
> >The validate attribute would describe an algorithm to employ and a result
> >to compare it to; for example, somebody downloading the en-US version
>
On Fri, 27 Jan 2006 00:07:54 +0600, James Graham <[EMAIL PROTECTED]> wrote:
This confirms the point that the classification of elements into
block-level and inline-level is just a convention not backed by a
semantic requirement.
Of course it can be. What does:
mean?
OK, I'm not advo
Alexey Feldgendler wrote:
On Thu, 26 Jan 2006 21:09:44 +0600, Anne van Kesteren
has never been defined in a way that it could give entire paragraphs
emphasis. I'm not really saying anything is wrong about it, just that
has never been defined. Also, was defined to be inline-level
(nothing
to
On Thu, 26 Jan 2006 21:09:44 +0600, Anne van Kesteren
<[EMAIL PROTECTED]> wrote:
The simplest, and actually the one being discussed:
Paragraph 1
Paragraph 2
Why not? These two paragraphs are highlighted with emphasis. What's
wrong here, in the semantical sense?
has never been de
Lachlan Hunt wrote:
XYZ
Mozilla:
BODY
+ EM
+ P
+ SPAN
+ H1
+ EM
+ #text: X
+ #text: YZ
That look reasonably like what the author would want with that rubbish,
except that the Z is within the span, but it's not in the markup. If
you swap with ,
Quoting Alexey Feldgendler <[EMAIL PROTECTED]>:
The simplest, and actually the one being discussed:
Paragraph 1
Paragraph 2
Why not? These two paragraphs are highlighted with emphasis. What's
wrong here, in the semantical sense?
has never been defined in a way that it could give enti
On Thu, 26 Jan 2006 08:57:55 +0600, Lachlan Hunt
<[EMAIL PROTECTED]> wrote:
Semantically, it makes no sense at all to put a block level element
within an inline element.
Because CSS lets you redefine what's inline and what's block by means
of the display property, there sometimes is sens
Hi,
From: Ian Hickson <[EMAIL PROTECTED]>
This breaks in the face of , sadly (see my earlier mail).
Otherwise I'd agree.
Ok. Then what Safari does makes most sense to me. What Mozilla does seems
too complicated and unpredictable.
Regards,
Simon Pieters
18 matches
Mail list logo
