On Thu, 26 Jan 2006, Billy Wong wrote:
>
> When somebody want a hyperlink work for one or more block(s) including
> the inside space and border, it make sense to most to put href="">... Currently, in order to do the same thing and
> remain "conformable", people need to do pointless hack like on
On Wed, 25 Jan 2006, liorean wrote:
>
> On 25/01/06, Henri Sivonen <[EMAIL PROTECTED]> wrote:
> > On Jan 25, 2006, at 19:50, liorean wrote:
> > > So, how about dropping id uniqueness then?
> > UAs will have deal with author-introduced duplicate ids anyway, so
> > parser-introduced duplicates are no
On Sun, 29 Jan 2006, Henri Sivonen wrote:
> >
> > I understood your system to be:
> >
> >[TOKENISER] --> [PREPROCESSOR] --> [PARSER]
> >
> > ...where the preprocessor rearranges tokens, and the parser creates
> > the DOM. How does your system handle the cases above without blocking
> > in
On Jan 27, 2006, at 09:16, Ian Hickson wrote:
In that case I don't understand your proposal.
We need something that, given this:
X
...results in this DOM:
BODY
EM
P
...and given this:
X
...results in this DOM:
BODY
EM
P
EM
Given that "X" can be a
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
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 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
On 1/26/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
> Billy Wong wrote:
> > On 1/26/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
> >> No, you just need to use the a element and set
> >>a { display: block; height: Y; width: X; }
> >>
> >> You may not even need to set the width or height or you ma
I have to ask - why reopen the tags? Why not throw them on the floor? They're
wrong anyhow and cause problems. If bad code didn't (sort of) work, people
would write different code. That would be good.
IOW:
stuff looks like
Body
+em
+p
+stuff
[EMAIL PROTECTED] wrote:
For example,
We used to not reopen the tags. It was the #1 rendering bug in our
engine. We had over 60 unique duplicates of the bug in our internal
database. All that would happen if we didn't reopen the tags is that
people would switch to another browser. :)
dave
On Jan 25, 2006, at 11:31 PM, Blanc
On 1/26/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
> Alexey Feldgendler wrote:
> > On Thu, 26 Jan 2006 08:34:38 +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 yo
Alexey Feldgendler wrote:
On Thu, 26 Jan 2006 08:34:38 +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,
Ian Hickson wrote:
On Wed, 25 Jan 2006, Lachlan Hunt wrote:
1.
XY
BODY
+ P
+ EM
+ #text: X
+ #text: Y
This is what the spec currently says. I got pretty strong feedback from
browser devs that it wasn't acceptable. There are performance concerns,
but the biggest problem with
On Thu, 26 Jan 2006 08:34:38 +0600, Lachlan Hunt
<[EMAIL PROTECTED]> wrote:
But I am still not clever enough to grasp it. For
"", what is pratically preventing
it from being a sane document tree, so that it has to be defined
invalid in HTML 4.01?
Nothing is preventing that from being a well
Billy Wong wrote:
On 1/26/06, Henri Sivonen <[EMAIL PROTECTED]> wrote:
On Jan 25, 2006, at 17:17, Billy Wong wrote:
Sorry. I don't notice that this is invaild. I am new here. What
makes inline-level element not feasible to contain block-level
elements??
The HTML 4.01 Transitional DTD. Geck
On 1/26/06, Henri Sivonen <[EMAIL PROTECTED]> wrote:
> On Jan 25, 2006, at 17:17, Billy Wong wrote:
>
> > Sorry. I don't notice that this is invaild. I am new here. What
> > makes inline-level element not feasible to contain block-level
> > elements??
>
> The HTML 4.01 Transitional DTD. Gecko an
My 2 cents.
It took me a long time to develop an algorithm that actually fixed
all 60 of the duplicate internal Apple bugs on this subject. I'm
reluctant to revisit this problem in our code base, given that my
current algorithm was developed both to solve the problem and to be
extremely
On Wed, 25 Jan 2006, Simon Pieters wrote:
>
> When do you insert the EM element node to the DOM? Should the parser
> wait with inserting it until it knows what comes next? I think it makes
> more sense to just insert the element when you have parsed the start
> tag, regardless of what comes next
On Wed, 25 Jan 2006, Simon Pieters wrote:
>
> Thus, XY should be parsed as:
>
> BODY
> + EM
> + P
> + EM
> + #text: XY
>
> ...IMHO.
This breaks in the face of , sadly (see my earlier mail).
Otherwise I'd agree.
--
Ian Hickson U+1047E)\._.,--,'``
On Wed, 25 Jan 2006, liorean wrote:
>
> [...]
Interesting summary of the possibilities.
> Well, the obvious problems with [not caring about creating duplicate IDs
> in the face of misnested tags] are for things like ::before in CSS or
> getElementById in the DOM. We have two different #Y elem
On Wed, 25 Jan 2006, Billy Wong wrote:
>
> First, my idea would not, and should not, break the whole web. If it is
> really deployed, it would only break webpage that are not well-formed in
> this particular way.
That's a large fraction of the Web.
> Second, this discussion begins to be for e
On Wed, 25 Jan 2006, Billy Wong wrote:
>
> Example: XY
> + span
> + div
> + #text: X
> + #text: Y
This doesn't work, because it would put a line break between the X and the
Y. This breaks real-world sites and would not be acceptable.
> To correctly written webpages, this should pose no
On Wed, 25 Jan 2006, Lachlan Hunt wrote:
>
> IE6:
> HTML
> + HEAD
> + TITLE
> + BODY
> + SPAN
> + P
> + #text: X
> + #text: Y
> + #text: Y (Highlighted in red in the DOM view)
FYI the red means that the node was in the parent node's childNodes list,
but th
On Wed, 25 Jan 2006, Lachlan Hunt wrote:
>
> However, there may be a 5th option available. Consider this, using the
> following markup samples from the article.
>
> 1.
> XY
>
> BODY
> + P
> + EM
> + #text: X
> + #text: Y
>
> The theory is that any inline elements started and no
On 25/01/06, Henri Sivonen <[EMAIL PROTECTED]> wrote:
> On Jan 25, 2006, at 19:50, liorean wrote:
> > So, how about dropping id uniqueness then?
> UAs will have deal with author-introduced duplicate ids anyway, so
> parser-introduced duplicates are not a big deal.
Well, the difference is that they
On Jan 25, 2006, at 19:50, liorean wrote:
So, how about dropping id uniqueness then?
UAs will have deal with author-introduced duplicate ids anyway, so
parser-introduced duplicates are not a big deal.
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
I don't think there's any solution that doesn't break in some way.
Either we break content to element mappings, we break the single
parent relation, or we break the id to element or content mapping.
E.g:
ABC
How do we keep all of those relations? We simply can't keep them all.
For example, i
On Jan 25, 2006, at 17:17, Billy Wong wrote:
Sorry. I don't notice that this is invaild. I am new here. What
makes inline-level element not feasible to contain block-level
elements??
The HTML 4.01 Transitional DTD. Gecko and WebCore try to force the
document tree to be a sane Transitional
On Jan 25, 2006, at 15:15, Lachlan Hunt wrote:
I don't think there's much advantage of differentiating between
"well-formed" and "malformed" markup. They should be parsed the
same to keep things simple and predictable. Thus, XYem> should be parsed as:
BODY
+ EM
+ P
+ EM
+ #text
On Jan 25, 2006, at 12:09, Lachlan Hunt wrote:
This is in response to Hixie's article [1].
I had had such a strong intuitive assumption of what Gecko and
WebCore were doing that I was surprised to learn their behavior is
indeed much hairier. (I hadn't even verified my assumption by
check
On 1/25/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
> Billy Wong wrote:
> > On 1/25/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
> >> I'm not saying it won't break anything, but every single change we make
> >> to the parsing could possibly break any number of the billions of pages
> >> on the web i
Hi,
From: Lachlan Hunt <[EMAIL PROTECTED]>
Because there were no text nodes between the start-tag and the
start tag, so putting it in there would be completely redundant and
useless. Although putting it there will have no detrimental effect beyond
wasting a minuscule amount of memory, so it
Simon Pieters wrote:
Hi,
From: Lachlan Hunt <[EMAIL PROTECTED]>
However, there may be a 5th option available. Consider this, using
the following markup samples from the article.
1.
XY
BODY
+ P
+ EM
+ #text: X
+ #text: Y
Why would you drop the first EM? Why should this be p
Billy Wong wrote:
On 1/25/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
I'm not saying it won't break anything, but every single change we make
to the parsing could possibly break any number of the billions of pages
on the web in any number of browsers.
But using your method (swapping inline nod
Hi,
From: Lachlan Hunt <[EMAIL PROTECTED]>
However, there may be a 5th option available. Consider this, using the
following markup samples from the article.
1.
XY
BODY
+ P
+ EM
+ #text: X
+ #text: Y
Why would you drop the first EM? Why should this be parsed any different
t
On 1/25/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
> I'm not saying it won't break anything, but every single change we make
> to the parsing could possibly break any number of the billions of pages
> on the web in any number of browsers.
But using your method (swapping inline node and block node
Anne van Kesteren wrote:
Quoting Lachlan Hunt <[EMAIL PROTECTED]>:
1.
XY
BODY
+ P
+ EM
+ #text: X
+ #text: Y
The theory is that any inline elements
This gives problems for new elements I assume... We already have a
problem with
test...
I don't see how this affects new ele
Quoting Lachlan Hunt <[EMAIL PROTECTED]>:
1.
XY
BODY
+ P
+ EM
+ #text: X
+ #text: Y
The theory is that any inline elements
This gives problems for new elements I assume... We already have a
problem with
test...
2.
XY
BODY
+ P
+ EM
+ #text: X
+ #text: Y
Hi,
This is in response to Hixie's article [1].
I fully agree that the both IE's incestual approach and Opera's genetic
inheritance problem (though a well-formed tree) are out of the question.
I like the Hiesenburg theory in some cases, although its lack of easy
predictability is a big down
50 matches
Mail list logo
