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 a
href=div.../div/a Currently, in order to do the same thing and
remain conformable, people need to do pointless hack like
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 the preprocessor
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 sense
Quoting Alexey Feldgendler [EMAIL PROTECTED]:
The simplest, and actually the one being discussed:
em
pParagraph 1/p
pParagraph 2/p
/em
Why not? These two paragraphs are highlighted with emphasis. What's
wrong here, in the semantical sense?
em has never been defined in a way that it
Lachlan Hunt wrote:
!DOCTYPE html
empspanh1X/emY/spanZ/h1/p
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
On Thu, 26 Jan 2006 21:09:44 +0600, Anne van Kesteren
[EMAIL PROTECTED] wrote:
The simplest, and actually the one being discussed:
em
pParagraph 1/p
pParagraph 2/p
/em
Why not? These two paragraphs are highlighted with emphasis. What's
wrong here, in the semantical sense?
em has
Alexey Feldgendler wrote:
On Thu, 26 Jan 2006 21:09:44 +0600, Anne van Kesteren
em 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, em was defined to be inline-level
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
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.
!DOCTYPE html
empspanh1X/emY/spanZ/h1/p
Mozilla:
BODY
+ EM
+ P
+ SPAN
+ H1
Alexey Feldgendler wrote:
On Thu, 26 Jan 2006 21:09:44 +0600, Anne van Kesteren
[EMAIL PROTECTED] wrote:
em 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, em was defined to
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
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)
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.
empX/emY/p
BODY
+ P
+ EM
+ #text: X
+ #text: Y
Why would you drop the first EM? Why should this be parsed any
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 node
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.
empX/emY/p
BODY
+ P
+ EM
+ #text: X
+ #text: Y
Why would you drop the first EM? Why should
Hi,
From: Lachlan Hunt [EMAIL PROTECTED]
Because there were no text nodes between the em start-tag and the p
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
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 in any number of
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
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, empXY/p/
em should be parsed as:
BODY
+ EM
+ P
+ EM
+
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/
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.
empX/emY/p
BODY
+ P
+ EM
+ #text: X
+ #text: Y
The theory is that any inline elements started and not
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
On Wed, 25 Jan 2006, Simon Pieters wrote:
Thus, empXY/p/em should be parsed as:
BODY
+ EM
+ P
+ EM
+ #text: XY
...IMHO.
This breaks in the face of ah3/h3//a, sadly (see my earlier mail).
Otherwise I'd agree.
--
Ian Hickson U+1047E
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.
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 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 you redefine what's
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,
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 may need to set
28 matches
Mail list logo
