date:20091013

Re: [whatwg] framesets

2009-10-13 Thread Brian Campbell

On Oct 13, 2009, at 11:20 PM, Peter Brawley wrote:

Ian,

> Your requirements aren't met by framesets

Eh? Our solution meets the requirement and uses framesets.

You have specified that your requirement is to prevent people from
linking to or bookmarking individual pages inside of frames. Framesets
do not satisfy that requirement. They make it a little more difficult,
but they do not prevent it.

> s have been demonstrated to work as well as framesets

No-one's been able to point to a working non-frameset solution that
meets this requirement.

Ian posted one, had-written just for you, which you dismissed without
giving any reason.

>, and, well, framesets suck.

Unargued, subjective.

Framesets suck because they combine both layout and embedding
semantics into one syntax, which give them much less layout
flexibility than using CSS. Anything you can do with framesets (except
resizing), you can do with iframes and CSS. However, there are lots of
things you can do with iframes and CSS that you cannot do with
framesets. Framesets are a completely different language than HTML;
you cannot use framesets and any other content elements in the same
document. This means that you are forced to, for example, use a frame
for the header of your page, which may cause a scrollbar to appear if
you don't allocate enough space, rather than just putting the header
in the page directly and using iframes to include the other pages.

>I agree that there's
>lots of legacy content using framesets; that's why HTML5 defines
how they

>should work (in more detail than any previous spec!).

?! According to http://www.html5code.com/index.php/html-5-tags/html-5-frameset-tag/
, "The frameset tag is not supported in HTML 5."

That is not the draft HTML5 spec. I'm not sure what that is, but as
far as I know, it has no official affiliation with either the W3C or
the WHATWG. Try: http://whatwg.org/html5 or more specifically:

http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#frames-and-framesets

The HTML5 spec includes two types of conformance requirements;
conformance requirements for authors (or other producers of HTML), and
conformance requirements for user agents (browser and other consumers
of HTML). It is non-conforming in HTML5 to produce documents with
framesets, however a conforming user agent must parse and process them
consistently with the spec.

>The only thing that is easier with framesets than otherwise appears
to be

>resizing, which I agree is not well-handled currently.

Unsubstantiated claim absent a working example of the spec
implemented without framesets.

Did you take a look at Ian's example?

http://damowmow.com/playground/demos/framesets-with-iframes/001.html

>As noted before,
>though, that's an issue for more than just frames; we need a good
solution
>for this in general, whether we have framesets or not. Furthermore,
that's

>a styling issue, not an HTML issue.

For those who have to write or generate HTML, that's a distinction
without a difference.

Ian Hickson wrote:

On Tue, 13 Oct 2009, Peter Brawley wrote:

I don't know if there are pages that do this (and I sure hope
none are

using for it!), but the lack of an existence proof is not
proof of the lack of existence.

Of course. The point is if no-one can point to a working iframes
solution, ie, to an instance of them actually being preferred, the
claim
that iframes provide a preferable alternative is simply not
credible, to

put it mildly.

At this point I don't really understand what you want framesets
for. Your
requirements aren't met by framesets, s have been
demonstrated to
work as well as framesets, and, well, framesets suck. I agree that
there's
lots of legacy content using framesets; that's why HTML5 defines
how they
should work (in more detail than any previous spec!). But that
doesn't

mean we should encourage them.

The only thing that is easier with framesets than otherwise appears
to be
resizing, which I agree is not well-handled currently. As noted
before,
though, that's an issue for more than just frames; we need a good
solution
for this in general, whether we have framesets or not. Furthermore,
that's

a styling issue, not an HTML issue.

No virus found in this incoming message.
Checked by AVG -
www.avg.com

Version: 8.5.421 / Virus Database: 270.14.13/2432 - Release Date:
10/13/09 06:35:00

Re: [whatwg] Navigation events generated during unload

2009-10-13 Thread Boris Zbarsky


On 10/13/09 10:58 PM, Ian Hickson wrote:

Ah, I see. Yes, that makes sense. Are you ok with what the spec says
despite this minor difference? (It seems that what the spec says is a mote
more self-consistent, but I could be biased! ;-) )


Can you point me to the relevant spec text?

And note that I did say that the current Gecko behavior for link/iframe 
was expedient, not designed, right?  ;)


-Boris

Re: [whatwg] localStorage feedback

2009-10-13 Thread Brett Cannon

Found how to subscribe to the webapps list. Turns out I was trying to join
the working group and not the mailing list.

On Tue, Oct 13, 2009 at 16:28, Ian Hickson  wrote:

> On Tue, 13 Oct 2009, Jeremy Orlow wrote:
> > On Tue, Oct 13, 2009 at 3:40 PM, Ian Hickson  wrote:
> > > On Tue, 13 Oct 2009, Brett Cannon wrote:
> > > > On Mon, Oct 12, 2009 at 19:07, Ian Hickson  wrote:
> > > > >
> > > > > I believe you can test if a key is in the storage area using:
> > > > >
> > > > >   if (key in storage) { ... }
> > > > >
> > > > > For example:
> > > > >
> > > > >   if ('document' in window.localStorage) { ... }
> > > >
> > > > I didn't find that in the spec anywhere. Is it somehow implicit and I
> > > > just missed it? Or will it be specified sometime in the future?
> > >
> > > It's the net effect of this line in the spec:
> > >
> > > # The names of the supported named properties on a Storage object are
> the
> > > # keys of each key/value pair currently present in the list associated
> > > # with the object.
> > >
> > > ...combined with the definitions in the WebIDL spec.
> >
> > It seems odd that there wouldn't be a corresponding method on
> > localStorage given that the deleter, getter, and setter all have them.
>
> Personally I'd rather remove those methods, but I think we're stuck with
> them at this point.

While usability does go up when you use things like setting keys/values
directly off of localStorage instead of using setItem(), etc. it does make
it much more difficult to provide a drop-in library to provide enhanced
features and fix compatibility issues thanks to JavaScript not supporting
thorough operator overloading. For instance, IE 8 doesn't provide a way to
do an equivalent 'length' attribute (until ECMAScript 5 is supported). And I
have no clue how to potentially fix any browser incompatibility that the
'in' operator might introduce.

And taking away the functions would force people like me to come up with
their own API instead of using the defined functions. Providing functions
mirroring things you can do directly with an object might be a pain, but it
does help overcome a shortcoming of JavaScript.

-Brett

42 matches

Mail list logo