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
Replying to myself...
On 20 Jun 2005 at 15:52, Hallvord Reiar Michaelsen Ste wrote:
Commenting on
http://www.whatwg.org/specs/web-apps/current-work/#setrequestheader
X
I'm not sure why we disallow normal headers at all.
X
Would it be better if the spec just stated what headers could be
On 22 Jun 2005 at 16:57, Hallvord Reiar Michaelsen Ste wrote:
Spec says about responseXML :
If the document was not an XML document, or if the document could
not be parsed (due to an XML well-formedness error or unsupported
character encoding, for instance), returns null.
All major
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/
Google recently published some (not-very-scientific) research which
people on this list will probably find interesting:
http://code.google.com/webstats/index.html
I plan to use this data to guide the development of HTML5. In particular,
we probably need a copyright element. I was glad to
Hi,
From: Ian Hickson [EMAIL PROTECTED]
Google recently published some (not-very-scientific) research which
people on this list will probably find interesting:
http://code.google.com/webstats/index.html
On the table elements page[1]:
If someone can explain why so many pages would use a
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
of FF 1.5 from the Mozilla.com homepage could click on a link like
[a
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
On Jan 25, 2006, at 12:45 PM, Ian Hickson wrote:
Google recently published some (not-very-scientific) research which
people on this list will probably find interesting:
http://code.google.com/webstats/index.html
I plan to use this data to guide the development of HTML5. In
particular,
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
24 matches
Mail list logo
