W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: frameset-ok as flag vs. insertion mode

From: Henri Sivonen <hsivonen@iki.fi>
Date: Tue, 24 Feb 2009 09:34:41 +0200
Cc: HTMLWG WG <public-html@w3.org>
Message-Id: <F29F54B9-5D1C-4CF5-A9F7-31810C4120C1@iki.fi>
To: Ian Hickson <ian@hixie.ch>
On Feb 24, 2009, at 00:12, Ian Hickson wrote:

> On Mon, 23 Feb 2009, Henri Sivonen wrote:
>>
>> Is there a reason why frameset-ok is defined as a flag instead of  
>> being
>> defined as a insertion mode between 'after head' and 'in body'?
>
> Is it equivalent?

It sure looks like it.

The insertion mode would have a three-way switch:

1. frameset
2. all the things that now set frameset-ok to 'not ok' would set the  
insertion mode to 'in body' and immediately fall through to 'in body'.
3. everything else just falls through to 'in body'

> I was reluctant to split the "in body" mode in two, with
> one mode basically just forwarding everything to the other mode, so I
> didn't really check to see if it would have worked.

I don't understand the reluctance here.

> For example, how would you handle the switch to and from the "in  
> CDATA" mode, without yet another
> way of keeping track which mode we came from?


'in CDATA/RCDATA' already requires another variable for holding the  
original mode. On the face of it, it seems to me that treating  
'frameset-ok' as an insertion mode wouldn't add any new variables, and  
<script>, <style> and <noscript> in 'frameset-ok' would set the  
original mode variable (which would already happen given existing spec  
text and code) and transitions out of 'in CDATA/RCDATA' would need to  
use the code that's already there for restoring the mode.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Tuesday, 24 February 2009 07:35:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:01 UTC