From webmaster at tsmchughs.com  Mon Dec  5 20:12:10 2011
From: webmaster at tsmchughs.com (Brian Tremblay)
Date: Mon, 05 Dec 2011 20:12:10 -0800
Subject: [html5] empty cells
In-Reply-To: <Pine.LNX.4.64.1105120159240.19153@ps20323.dreamhostps.com>
References: <4D8678FB.2090107@tsmchughs.com>
	<Pine.LNX.4.64.1105120159240.19153@ps20323.dreamhostps.com>
Message-ID: <4EDD961A.1010704@tsmchughs.com>

On 5/11/11 8:00 PM, Ian Hickson wrote:
> On Sun, 20 Mar 2011, webmaster wrote:
>>
>> I'm seeing what I think is a bug in Safari with regard to empty cells in
>> a table. I have a restaurant dinner menu marked up as a table:
>>
>> http://www.tenmercer.com/menu/dinner
>>
>> The first tr of each tbody element contains only a th element.
>> Each subsequent tr has 3 cells: a th and two tds. My style
>> sheet has a rule to place a border-bottom on tbody tr:first-child. In
>> Firefox, the border extends across the table, but not in Safari.
>
> Yeah, that seems like a bug in the CSS border rendering for tables. I
> recommend filing a bug at http://bugs.webkit.org/. Feel free to cc me
> (ian at hixie.ch is my account).

I never did file the bug. I've now created 2 test cases:

http://btrem.com/tests/table2

This is a simplified test case of the bug I first noticed on the 
tenmercer.com site (see url in quoted text above). Firefox gets it 
right; webkit does not.

http://btrem.com/tests/table1

This is a test case using the separate border model and border around 
<td> elements. Firefox and webkit get this one wrong (unless I 
misunderstand the border model).

If the tests look correct to you, I'm going to file the bugs.

-- 
Brian Tremblay

From ian at hixie.ch  Tue Dec 13 13:53:47 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 13 Dec 2011 21:53:47 +0000 (UTC)
Subject: [html5] Incremental rendering of XHTML5
In-Reply-To: <CAAuwN4FRWtBQZPoBaCu-wHV-Skk7sFp72B-pmm-y+4Pf1QWreQ@mail.gmail.com>
References: <CAAuwN4Gr4mk0s9vQ9uBYpZGHgd-ofpZRCDC_ROdtK-OmD+1tJw@mail.gmail.com>
	<Pine.LNX.4.64.1108112009210.9174@ps20323.dreamhostps.com>
	<CAAuwN4FRWtBQZPoBaCu-wHV-Skk7sFp72B-pmm-y+4Pf1QWreQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1112132149070.18028@ps20323.dreamhostps.com>

On Fri, 12 Aug 2011, Jesper Tverskov wrote:
> 
> I have not understood why an XML parser for webpages doesn't have the 
> potential of being faster than a HTML parser. Most HTML parsers are able 
> to repair the markup and to show something useful no matter how much 
> code is missing.

The basic answer is that it is no more expensive to correct such mistakes 
than it is to abort when you hit such mistakes. In fact in many cases it 
can be quicker to not look to see if there is a mistake, which can make 
HTML parsing actually quicker in theory in some cases.

An analogy:

An XML parser is like a car driven by someone who carefully checks that 
he's not going to drive into anything. If there's anything on the road, he 
stops and doesn't go any further.

An HTML parser, on the other hand, is like a car driven by someone who 
doesn't check to see if there's anything in the road, he just plows 
straight through.

When there's nothing on the road, the reckless HTML parser car can go 
faster than the careful XML parser car can. On the other hand, when 
there's something in the way (i.e. a markup error), the results are 
predictable with the XML car -- it stops. But with the HTML car, the 
results can be negligible (e.g. driving straight over a newspaper on the 
road, analogous to a minor syntax error), or they can be spectacular (e.g. 
driving into a big rock, analogous to a syntax error with noticeable error 
handling, like unexpected text in a <table>).

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From ian at hixie.ch  Tue Dec 13 14:14:52 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 13 Dec 2011 22:14:52 +0000 (UTC)
Subject: [html5] empty cells
In-Reply-To: <4EDD961A.1010704@tsmchughs.com>
References: <4D8678FB.2090107@tsmchughs.com>
	<Pine.LNX.4.64.1105120159240.19153@ps20323.dreamhostps.com>
	<4EDD961A.1010704@tsmchughs.com>
Message-ID: <Pine.LNX.4.64.1112132213330.6235@ps20323.dreamhostps.com>

On Mon, 5 Dec 2011, Brian Tremblay wrote:
> >
> > Yeah, that seems like a bug in the CSS border rendering for tables. I 
> > recommend filing a bug at http://bugs.webkit.org/. Feel free to cc me 
> > (ian at hixie.ch is my account).
> 
> I never did file the bug. I've now created 2 test cases:
> 
> http://btrem.com/tests/table2
> 
> This is a simplified test case of the bug I first noticed on the 
> tenmercer.com site (see url in quoted text above). Firefox gets it 
> right; webkit does not.

I'm told this particular bug is already filed on WebKit.


> http://btrem.com/tests/table1
> 
> This is a test case using the separate border model and border around 
> <td> elements. Firefox and webkit get this one wrong (unless I 
> misunderstand the border model).

For this one there is no cell in the bottom right corner, so there's 
nothing for CSS to render. So I think the browsers are doing the right 
thing.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From lelifeng at 139.com  Wed Dec 14 02:36:31 2011
From: lelifeng at 139.com (lelifeng at 139.com)
Date: Wed, 14 Dec 2011 18:36:31 +0800 (CST)
Subject: [html5] Hi, everybody,
 there is a question beg for your attention. " Can Adobe AIR support
 Websocket Protocol Now?"
Message-ID: <aec34c.202b9.1343c2519a0.Coremail.lelifeng@139.com>

FIY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20111214/f3921747/attachment.htm>

From derernst at gmx.ch  Thu Dec 22 01:59:25 2011
From: derernst at gmx.ch (Markus Ernst)
Date: Thu, 22 Dec 2011 10:59:25 +0100
Subject: [html5] Is it safe to remove an element from within the element?
Message-ID: <4EF2FF7D.1080305@gmx.ch>

Hello

I hope my question is not too basic for this mailing list, resp. the 
answer too obvious - googling for it is difficult, as possible search 
terms lead to tons of tutorials on removing elements, but not discussing 
this question.

I have a message for non-JS UAs:

<div id="jsMsg">
   <p>Javascript is turned off or not available in your browser. While
     the basic functionalities will work like this, some functions, such
     as "cancel"-buttons, might not work as expected.</p>
   <script type="text/javascript">
     var jsMsg = document.getElementById("jsMsg");
     jsMsg.parentNode.removeChild(jsMsg);
   </script>
</div>

This looks like a clean solution to me, as it is removing from the DOM 
both the element and the script to remove it. I found no problems with 
this code in Firefox 5.0 and Internet Explorer 9.

Anyway, as the removing mechanism is triggered in the code before the 
element is actually closed, I ask myself whether this works by design, 
or just accidentally.

Thanks for a comment!
Markus

From bhawkeslewis at googlemail.com  Thu Dec 22 06:32:12 2011
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Thu, 22 Dec 2011 14:32:12 +0000
Subject: [html5] Is it safe to remove an element from within the element?
In-Reply-To: <4EF2FF7D.1080305@gmx.ch>
References: <4EF2FF7D.1080305@gmx.ch>
Message-ID: <CAEhSh3f-CDsmY4AoXRnORSuZ95JnC-aZRSLtoxXmnKtVS1euCw@mail.gmail.com>

On Thu, Dec 22, 2011 at 9:59 AM, Markus Ernst <derernst at gmx.ch> wrote:
> I have a message for non-JS UAs:
>
> <div id="jsMsg">
> ?<p>Javascript is turned off or not available in your browser. While
> ? ?the basic functionalities will work like this, some functions, such
> ? ?as "cancel"-buttons, might not work as expected.</p>
> ?<script type="text/javascript">
> ? ?var jsMsg = document.getElementById("jsMsg");
> ? ?jsMsg.parentNode.removeChild(jsMsg);
> ?</script>
> </div>
>
> This looks like a clean solution to me, as it is removing from the DOM both
> the element and the script to remove it. I found no problems with this code
> in Firefox 5.0 and Internet Explorer 9.
>
> Anyway, as the removing mechanism is triggered in the code before the
> element is actually closed, I ask myself whether this works by design, or
> just accidentally.

I think you'll find the <div> and <script> elements are already parsed
into the DOM before the script is executed.

--
Benjamin Hawkes-Lewis

From jukka.k.korpela at kolumbus.fi  Thu Dec 22 07:48:58 2011
From: jukka.k.korpela at kolumbus.fi (Jukka K. Korpela)
Date: Thu, 22 Dec 2011 17:48:58 +0200
Subject: [html5] Is it safe to remove an element from within the element?
In-Reply-To: <4EF2FF7D.1080305@gmx.ch>
References: <4EF2FF7D.1080305@gmx.ch>
Message-ID: <4EF3516A.9040708@kolumbus.fi>

2011-12-22 11:59, Markus Ernst wrote:

> I have a message for non-JS UAs:
>
> <div id="jsMsg">
> <p>Javascript is turned off or not available in your browser. While
> the basic functionalities will work like this, some functions, such
> as "cancel"-buttons, might not work as expected.</p>
> <script type="text/javascript">
> var jsMsg = document.getElementById("jsMsg");
> jsMsg.parentNode.removeChild(jsMsg);
> </script>
> </div>
>
> This looks like a clean solution to me, as it is removing from the DOM
> both the element and the script to remove it.

I don't see why would need to remove the code as well. But more 
importantly, is there a reason not to use the simple <noscript> element?

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

From webmaster at tsmchughs.com  Mon Dec  5 20:12:10 2011
From: webmaster at tsmchughs.com (Brian Tremblay)
Date: Mon, 05 Dec 2011 20:12:10 -0800
Subject: [html5] empty cells
In-Reply-To: <Pine.LNX.4.64.1105120159240.19153@ps20323.dreamhostps.com>
References: <4D8678FB.2090107@tsmchughs.com>
	<Pine.LNX.4.64.1105120159240.19153@ps20323.dreamhostps.com>
Message-ID: <4EDD961A.1010704@tsmchughs.com>

On 5/11/11 8:00 PM, Ian Hickson wrote:
> On Sun, 20 Mar 2011, webmaster wrote:
>>
>> I'm seeing what I think is a bug in Safari with regard to empty cells in
>> a table. I have a restaurant dinner menu marked up as a table:
>>
>> http://www.tenmercer.com/menu/dinner
>>
>> The first tr of each tbody element contains only a th element.
>> Each subsequent tr has 3 cells: a th and two tds. My style
>> sheet has a rule to place a border-bottom on tbody tr:first-child. In
>> Firefox, the border extends across the table, but not in Safari.
>
> Yeah, that seems like a bug in the CSS border rendering for tables. I
> recommend filing a bug at http://bugs.webkit.org/. Feel free to cc me
> (ian at hixie.ch is my account).

I never did file the bug. I've now created 2 test cases:

http://btrem.com/tests/table2

This is a simplified test case of the bug I first noticed on the 
tenmercer.com site (see url in quoted text above). Firefox gets it 
right; webkit does not.

http://btrem.com/tests/table1

This is a test case using the separate border model and border around 
<td> elements. Firefox and webkit get this one wrong (unless I 
misunderstand the border model).

If the tests look correct to you, I'm going to file the bugs.

-- 
Brian Tremblay


From ian at hixie.ch  Tue Dec 13 13:53:47 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 13 Dec 2011 21:53:47 +0000 (UTC)
Subject: [html5] Incremental rendering of XHTML5
In-Reply-To: <CAAuwN4FRWtBQZPoBaCu-wHV-Skk7sFp72B-pmm-y+4Pf1QWreQ@mail.gmail.com>
References: <CAAuwN4Gr4mk0s9vQ9uBYpZGHgd-ofpZRCDC_ROdtK-OmD+1tJw@mail.gmail.com>
	<Pine.LNX.4.64.1108112009210.9174@ps20323.dreamhostps.com>
	<CAAuwN4FRWtBQZPoBaCu-wHV-Skk7sFp72B-pmm-y+4Pf1QWreQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1112132149070.18028@ps20323.dreamhostps.com>

On Fri, 12 Aug 2011, Jesper Tverskov wrote:
> 
> I have not understood why an XML parser for webpages doesn't have the 
> potential of being faster than a HTML parser. Most HTML parsers are able 
> to repair the markup and to show something useful no matter how much 
> code is missing.

The basic answer is that it is no more expensive to correct such mistakes 
than it is to abort when you hit such mistakes. In fact in many cases it 
can be quicker to not look to see if there is a mistake, which can make 
HTML parsing actually quicker in theory in some cases.

An analogy:

An XML parser is like a car driven by someone who carefully checks that 
he's not going to drive into anything. If there's anything on the road, he 
stops and doesn't go any further.

An HTML parser, on the other hand, is like a car driven by someone who 
doesn't check to see if there's anything in the road, he just plows 
straight through.

When there's nothing on the road, the reckless HTML parser car can go 
faster than the careful XML parser car can. On the other hand, when 
there's something in the way (i.e. a markup error), the results are 
predictable with the XML car -- it stops. But with the HTML car, the 
results can be negligible (e.g. driving straight over a newspaper on the 
road, analogous to a minor syntax error), or they can be spectacular (e.g. 
driving into a big rock, analogous to a syntax error with noticeable error 
handling, like unexpected text in a <table>).

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Dec 13 14:14:52 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 13 Dec 2011 22:14:52 +0000 (UTC)
Subject: [html5] empty cells
In-Reply-To: <4EDD961A.1010704@tsmchughs.com>
References: <4D8678FB.2090107@tsmchughs.com>
	<Pine.LNX.4.64.1105120159240.19153@ps20323.dreamhostps.com>
	<4EDD961A.1010704@tsmchughs.com>
Message-ID: <Pine.LNX.4.64.1112132213330.6235@ps20323.dreamhostps.com>

On Mon, 5 Dec 2011, Brian Tremblay wrote:
> >
> > Yeah, that seems like a bug in the CSS border rendering for tables. I 
> > recommend filing a bug at http://bugs.webkit.org/. Feel free to cc me 
> > (ian at hixie.ch is my account).
> 
> I never did file the bug. I've now created 2 test cases:
> 
> http://btrem.com/tests/table2
> 
> This is a simplified test case of the bug I first noticed on the 
> tenmercer.com site (see url in quoted text above). Firefox gets it 
> right; webkit does not.

I'm told this particular bug is already filed on WebKit.


> http://btrem.com/tests/table1
> 
> This is a test case using the separate border model and border around 
> <td> elements. Firefox and webkit get this one wrong (unless I 
> misunderstand the border model).

For this one there is no cell in the bottom right corner, so there's 
nothing for CSS to render. So I think the browsers are doing the right 
thing.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From lelifeng at 139.com  Wed Dec 14 02:36:31 2011
From: lelifeng at 139.com (lelifeng at 139.com)
Date: Wed, 14 Dec 2011 18:36:31 +0800 (CST)
Subject: [html5] Hi, everybody,
 there is a question beg for your attention. " Can Adobe AIR support
 Websocket Protocol Now?"
Message-ID: <aec34c.202b9.1343c2519a0.Coremail.lelifeng@139.com>

FIY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20111214/f3921747/attachment-0001.htm>

From derernst at gmx.ch  Thu Dec 22 01:59:25 2011
From: derernst at gmx.ch (Markus Ernst)
Date: Thu, 22 Dec 2011 10:59:25 +0100
Subject: [html5] Is it safe to remove an element from within the element?
Message-ID: <4EF2FF7D.1080305@gmx.ch>

Hello

I hope my question is not too basic for this mailing list, resp. the 
answer too obvious - googling for it is difficult, as possible search 
terms lead to tons of tutorials on removing elements, but not discussing 
this question.

I have a message for non-JS UAs:

<div id="jsMsg">
   <p>Javascript is turned off or not available in your browser. While
     the basic functionalities will work like this, some functions, such
     as "cancel"-buttons, might not work as expected.</p>
   <script type="text/javascript">
     var jsMsg = document.getElementById("jsMsg");
     jsMsg.parentNode.removeChild(jsMsg);
   </script>
</div>

This looks like a clean solution to me, as it is removing from the DOM 
both the element and the script to remove it. I found no problems with 
this code in Firefox 5.0 and Internet Explorer 9.

Anyway, as the removing mechanism is triggered in the code before the 
element is actually closed, I ask myself whether this works by design, 
or just accidentally.

Thanks for a comment!
Markus


From bhawkeslewis at googlemail.com  Thu Dec 22 06:32:12 2011
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Thu, 22 Dec 2011 14:32:12 +0000
Subject: [html5] Is it safe to remove an element from within the element?
In-Reply-To: <4EF2FF7D.1080305@gmx.ch>
References: <4EF2FF7D.1080305@gmx.ch>
Message-ID: <CAEhSh3f-CDsmY4AoXRnORSuZ95JnC-aZRSLtoxXmnKtVS1euCw@mail.gmail.com>

On Thu, Dec 22, 2011 at 9:59 AM, Markus Ernst <derernst at gmx.ch> wrote:
> I have a message for non-JS UAs:
>
> <div id="jsMsg">
> ?<p>Javascript is turned off or not available in your browser. While
> ? ?the basic functionalities will work like this, some functions, such
> ? ?as "cancel"-buttons, might not work as expected.</p>
> ?<script type="text/javascript">
> ? ?var jsMsg = document.getElementById("jsMsg");
> ? ?jsMsg.parentNode.removeChild(jsMsg);
> ?</script>
> </div>
>
> This looks like a clean solution to me, as it is removing from the DOM both
> the element and the script to remove it. I found no problems with this code
> in Firefox 5.0 and Internet Explorer 9.
>
> Anyway, as the removing mechanism is triggered in the code before the
> element is actually closed, I ask myself whether this works by design, or
> just accidentally.

I think you'll find the <div> and <script> elements are already parsed
into the DOM before the script is executed.

--
Benjamin Hawkes-Lewis


From jukka.k.korpela at kolumbus.fi  Thu Dec 22 07:48:58 2011
From: jukka.k.korpela at kolumbus.fi (Jukka K. Korpela)
Date: Thu, 22 Dec 2011 17:48:58 +0200
Subject: [html5] Is it safe to remove an element from within the element?
In-Reply-To: <4EF2FF7D.1080305@gmx.ch>
References: <4EF2FF7D.1080305@gmx.ch>
Message-ID: <4EF3516A.9040708@kolumbus.fi>

2011-12-22 11:59, Markus Ernst wrote:

> I have a message for non-JS UAs:
>
> <div id="jsMsg">
> <p>Javascript is turned off or not available in your browser. While
> the basic functionalities will work like this, some functions, such
> as "cancel"-buttons, might not work as expected.</p>
> <script type="text/javascript">
> var jsMsg = document.getElementById("jsMsg");
> jsMsg.parentNode.removeChild(jsMsg);
> </script>
> </div>
>
> This looks like a clean solution to me, as it is removing from the DOM
> both the element and the script to remove it.

I don't see why would need to remove the code as well. But more 
importantly, is there a reason not to use the simple <noscript> element?

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/


From webmaster at tsmchughs.com  Mon Dec  5 20:12:10 2011
From: webmaster at tsmchughs.com (Brian Tremblay)
Date: Mon, 05 Dec 2011 20:12:10 -0800
Subject: [html5] empty cells
In-Reply-To: <Pine.LNX.4.64.1105120159240.19153@ps20323.dreamhostps.com>
References: <4D8678FB.2090107@tsmchughs.com>
	<Pine.LNX.4.64.1105120159240.19153@ps20323.dreamhostps.com>
Message-ID: <4EDD961A.1010704@tsmchughs.com>

On 5/11/11 8:00 PM, Ian Hickson wrote:
> On Sun, 20 Mar 2011, webmaster wrote:
>>
>> I'm seeing what I think is a bug in Safari with regard to empty cells in
>> a table. I have a restaurant dinner menu marked up as a table:
>>
>> http://www.tenmercer.com/menu/dinner
>>
>> The first tr of each tbody element contains only a th element.
>> Each subsequent tr has 3 cells: a th and two tds. My style
>> sheet has a rule to place a border-bottom on tbody tr:first-child. In
>> Firefox, the border extends across the table, but not in Safari.
>
> Yeah, that seems like a bug in the CSS border rendering for tables. I
> recommend filing a bug at http://bugs.webkit.org/. Feel free to cc me
> (ian at hixie.ch is my account).

I never did file the bug. I've now created 2 test cases:

http://btrem.com/tests/table2

This is a simplified test case of the bug I first noticed on the 
tenmercer.com site (see url in quoted text above). Firefox gets it 
right; webkit does not.

http://btrem.com/tests/table1

This is a test case using the separate border model and border around 
<td> elements. Firefox and webkit get this one wrong (unless I 
misunderstand the border model).

If the tests look correct to you, I'm going to file the bugs.

-- 
Brian Tremblay


From ian at hixie.ch  Tue Dec 13 13:53:47 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 13 Dec 2011 21:53:47 +0000 (UTC)
Subject: [html5] Incremental rendering of XHTML5
In-Reply-To: <CAAuwN4FRWtBQZPoBaCu-wHV-Skk7sFp72B-pmm-y+4Pf1QWreQ@mail.gmail.com>
References: <CAAuwN4Gr4mk0s9vQ9uBYpZGHgd-ofpZRCDC_ROdtK-OmD+1tJw@mail.gmail.com>
	<Pine.LNX.4.64.1108112009210.9174@ps20323.dreamhostps.com>
	<CAAuwN4FRWtBQZPoBaCu-wHV-Skk7sFp72B-pmm-y+4Pf1QWreQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1112132149070.18028@ps20323.dreamhostps.com>

On Fri, 12 Aug 2011, Jesper Tverskov wrote:
> 
> I have not understood why an XML parser for webpages doesn't have the 
> potential of being faster than a HTML parser. Most HTML parsers are able 
> to repair the markup and to show something useful no matter how much 
> code is missing.

The basic answer is that it is no more expensive to correct such mistakes 
than it is to abort when you hit such mistakes. In fact in many cases it 
can be quicker to not look to see if there is a mistake, which can make 
HTML parsing actually quicker in theory in some cases.

An analogy:

An XML parser is like a car driven by someone who carefully checks that 
he's not going to drive into anything. If there's anything on the road, he 
stops and doesn't go any further.

An HTML parser, on the other hand, is like a car driven by someone who 
doesn't check to see if there's anything in the road, he just plows 
straight through.

When there's nothing on the road, the reckless HTML parser car can go 
faster than the careful XML parser car can. On the other hand, when 
there's something in the way (i.e. a markup error), the results are 
predictable with the XML car -- it stops. But with the HTML car, the 
results can be negligible (e.g. driving straight over a newspaper on the 
road, analogous to a minor syntax error), or they can be spectacular (e.g. 
driving into a big rock, analogous to a syntax error with noticeable error 
handling, like unexpected text in a <table>).

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Dec 13 14:14:52 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 13 Dec 2011 22:14:52 +0000 (UTC)
Subject: [html5] empty cells
In-Reply-To: <4EDD961A.1010704@tsmchughs.com>
References: <4D8678FB.2090107@tsmchughs.com>
	<Pine.LNX.4.64.1105120159240.19153@ps20323.dreamhostps.com>
	<4EDD961A.1010704@tsmchughs.com>
Message-ID: <Pine.LNX.4.64.1112132213330.6235@ps20323.dreamhostps.com>

On Mon, 5 Dec 2011, Brian Tremblay wrote:
> >
> > Yeah, that seems like a bug in the CSS border rendering for tables. I 
> > recommend filing a bug at http://bugs.webkit.org/. Feel free to cc me 
> > (ian at hixie.ch is my account).
> 
> I never did file the bug. I've now created 2 test cases:
> 
> http://btrem.com/tests/table2
> 
> This is a simplified test case of the bug I first noticed on the 
> tenmercer.com site (see url in quoted text above). Firefox gets it 
> right; webkit does not.

I'm told this particular bug is already filed on WebKit.


> http://btrem.com/tests/table1
> 
> This is a test case using the separate border model and border around 
> <td> elements. Firefox and webkit get this one wrong (unless I 
> misunderstand the border model).

For this one there is no cell in the bottom right corner, so there's 
nothing for CSS to render. So I think the browsers are doing the right 
thing.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From lelifeng at 139.com  Wed Dec 14 02:36:31 2011
From: lelifeng at 139.com (lelifeng at 139.com)
Date: Wed, 14 Dec 2011 18:36:31 +0800 (CST)
Subject: [html5] Hi, everybody,
 there is a question beg for your attention. " Can Adobe AIR support
 Websocket Protocol Now?"
Message-ID: <aec34c.202b9.1343c2519a0.Coremail.lelifeng@139.com>

FIY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20111214/f3921747/attachment-0002.htm>

From derernst at gmx.ch  Thu Dec 22 01:59:25 2011
From: derernst at gmx.ch (Markus Ernst)
Date: Thu, 22 Dec 2011 10:59:25 +0100
Subject: [html5] Is it safe to remove an element from within the element?
Message-ID: <4EF2FF7D.1080305@gmx.ch>

Hello

I hope my question is not too basic for this mailing list, resp. the 
answer too obvious - googling for it is difficult, as possible search 
terms lead to tons of tutorials on removing elements, but not discussing 
this question.

I have a message for non-JS UAs:

<div id="jsMsg">
   <p>Javascript is turned off or not available in your browser. While
     the basic functionalities will work like this, some functions, such
     as "cancel"-buttons, might not work as expected.</p>
   <script type="text/javascript">
     var jsMsg = document.getElementById("jsMsg");
     jsMsg.parentNode.removeChild(jsMsg);
   </script>
</div>

This looks like a clean solution to me, as it is removing from the DOM 
both the element and the script to remove it. I found no problems with 
this code in Firefox 5.0 and Internet Explorer 9.

Anyway, as the removing mechanism is triggered in the code before the 
element is actually closed, I ask myself whether this works by design, 
or just accidentally.

Thanks for a comment!
Markus


From bhawkeslewis at googlemail.com  Thu Dec 22 06:32:12 2011
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Thu, 22 Dec 2011 14:32:12 +0000
Subject: [html5] Is it safe to remove an element from within the element?
In-Reply-To: <4EF2FF7D.1080305@gmx.ch>
References: <4EF2FF7D.1080305@gmx.ch>
Message-ID: <CAEhSh3f-CDsmY4AoXRnORSuZ95JnC-aZRSLtoxXmnKtVS1euCw@mail.gmail.com>

On Thu, Dec 22, 2011 at 9:59 AM, Markus Ernst <derernst at gmx.ch> wrote:
> I have a message for non-JS UAs:
>
> <div id="jsMsg">
> ?<p>Javascript is turned off or not available in your browser. While
> ? ?the basic functionalities will work like this, some functions, such
> ? ?as "cancel"-buttons, might not work as expected.</p>
> ?<script type="text/javascript">
> ? ?var jsMsg = document.getElementById("jsMsg");
> ? ?jsMsg.parentNode.removeChild(jsMsg);
> ?</script>
> </div>
>
> This looks like a clean solution to me, as it is removing from the DOM both
> the element and the script to remove it. I found no problems with this code
> in Firefox 5.0 and Internet Explorer 9.
>
> Anyway, as the removing mechanism is triggered in the code before the
> element is actually closed, I ask myself whether this works by design, or
> just accidentally.

I think you'll find the <div> and <script> elements are already parsed
into the DOM before the script is executed.

--
Benjamin Hawkes-Lewis


From jukka.k.korpela at kolumbus.fi  Thu Dec 22 07:48:58 2011
From: jukka.k.korpela at kolumbus.fi (Jukka K. Korpela)
Date: Thu, 22 Dec 2011 17:48:58 +0200
Subject: [html5] Is it safe to remove an element from within the element?
In-Reply-To: <4EF2FF7D.1080305@gmx.ch>
References: <4EF2FF7D.1080305@gmx.ch>
Message-ID: <4EF3516A.9040708@kolumbus.fi>

2011-12-22 11:59, Markus Ernst wrote:

> I have a message for non-JS UAs:
>
> <div id="jsMsg">
> <p>Javascript is turned off or not available in your browser. While
> the basic functionalities will work like this, some functions, such
> as "cancel"-buttons, might not work as expected.</p>
> <script type="text/javascript">
> var jsMsg = document.getElementById("jsMsg");
> jsMsg.parentNode.removeChild(jsMsg);
> </script>
> </div>
>
> This looks like a clean solution to me, as it is removing from the DOM
> both the element and the script to remove it.

I don't see why would need to remove the code as well. But more 
importantly, is there a reason not to use the simple <noscript> element?

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/