Brian,
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.
Of course the frameset /by itself /doesn't
So it does not answer the question: if framesets are as you claim not needed
for the full spec, there should be lots of non-frameset sites which meet
this spec as efficiently as ours does.
Maybe there are not many sites because nobody wants this type of sites?
I hate this type of documentation
Ian Hickson i...@hixie.ch, 2009-10-14 03:41 +:
As far as I can see the options are as follows:
1. Drop support for details and figure for now, revisit it later.
2. Use legend, and don't expect to be able to use it in any browsers
sanely for a few years.
3. Use dt/dd, and
On Wed, Oct 14, 2009 at 1:04 PM, Andrew Scherkus scher...@google.comwrote:
We use a combination of in-memory and block-based caching for media
resources. There is no guarantee whatsoever on what is loaded. There's a
nice side benefit of allowing complete random access to the file if the
On 14/10/2009 04:41, Ian Hickson wrote:
On Tue, 29 Sep 2009, Dean Edwards wrote:
It's going to take a while for IE7 to go away. In the meantime it
becomes an education issue -- You can start using HTML5 except
details which will look OK in some browsers but completely break
others.
...and
On Thu, 8 Oct 2009, Robert O'Callahan wrote:
http://www.whatwg.org/specs/web-apps/current-work/#loading-the-media-resource
In the resource fetch algorithm, after we reach the NETWORK_LOADED state
in step 3 which indicates that all the data we need to play the resource
is now available
On Wed, Oct 14, 2009 at 05:41, Ian Hickson i...@hixie.ch wrote:
As far as I can see the options are as follows:
1. Drop support for details and figure for now, revisit it later.
2. Use legend, and don't expect to be able to use it in any browsers
sanely for a few years.
3. Use dt/dd,
On Wed, 23 Sep 2009, Simon Pieters wrote:
I'd like a way to use workers without having to use an external resource. This
would allow easier testing, mashups, small standalone apps, and so forth.
I agree that it makes sense to support this on the long run. However, for
the short run, I think
On Wed, 23 Sep 2009, Simon Pieters wrote:
DedicatedWorkerGlobalScope and SharedWorkerGlobalScope probably shouldn't have
[Supplemental].
Yes, they should -- it means that their definitions are just globbed onto
the definition of their ancestor, WorkerGlobalScope, as if there was one
On Wed, 23 Sep 2009, Simon Pieters wrote:
If the origin of the resulting absolute URL is not the same as the origin of
the script that invoked the constructor, then throw a security exception.
says step 3 of the Worker constructor.
I don't see security exception defined in HTML5. (HTML5
On Fri, 25 Sep 2009, Simon Pieters wrote:
http://www.whatwg.org/specs/web-workers/current-work/#interface-objects-and-constructors
seems to say that there must be no interface object for Worker and
SharedWorker, but the constructors are to be available, which doesn't
make any sense since
On Mon, 28 Sep 2009, Simon Pieters wrote:
WorkerUtils implement WindowTimers;
should be
WorkerUtils implements WindowTimers;
Fixed. Thanks.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._
On Tue, 29 Sep 2009, Zoltan Herczeg wrote:
In WebKit implementation of MessagePort the addEventListener(message,
...) does not enable the transmitting of messages. All messages are
actually discarded until a dummy function is assigned to onmessage.
That is a bug. The port message queue is
On Tue, 29 Sep 2009, Drew Wilson wrote:
The intent of the spec is fairly clear that addEventListener(message)
should not start the message queue dispatch - only setting the onmessage
attribute does that:
The first time a MessagePort #messageport object's
On Fri, 25 Sep 2009, Simon Pieters wrote:
Workers are new and seems very likely to be incompatible with existing
scripts. So it is not subject to legacy content with legacy encodings.
Therefore, we should be able to always use utf-8 for workers. Always
using utf-8 is simpler to implement
On Wed, 14 Oct 2009 12:08:19 +0200, Ian Hickson i...@hixie.ch wrote:
On Fri, 9 Oct 2009, Philip Jägenstedt wrote:
Since we're going to contradict the progress events spec anyway, I would
suggest dropping all 'loadend' events. They're just not very useful.
I've left it in the other cases,
On Wed, 14 Oct 2009 12:51:09 +0200, Philip Jägenstedt phil...@opera.com
wrote:
We added loadend just to comply with Progress Events. Now that we fire
simple events instead, please drop loadend again as it serves no purpose
at all. I doubt any browser has yet shipped an implementation firing
On 14 Oct 2009, at 11:06, Remco wrote:
2. Use legend, and don't expect to be able to use it in any
browsers
sanely for a few years.
3. Use dt/dd, and don't expect to be able to use it in old
versions
of IE without rather complicated and elaborate hacks for a few
years.
I am not
On Wed, 14 Oct 2009 12:58:17 +0200, Anne van Kesteren ann...@opera.com
wrote:
On Wed, 14 Oct 2009 12:51:09 +0200, Philip Jägenstedt
phil...@opera.com wrote:
We added loadend just to comply with Progress Events. Now that we fire
simple events instead, please drop loadend again as it serves
On Fri, 21 Aug 2009, Philip Jägenstedt wrote:
The spec says that properties can also themselves be groups of
name-value pairs, but this isn't exposed in a very convenient way in
the DOM API. The 'properties' DOM-property is a HTMLPropertyCollection
of all associated elements. Discovering
On Wed, 14 Oct 2009, Philip J�genstedt wrote:
On Wed, 14 Oct 2009 12:08:19 +0200, Ian Hickson i...@hixie.ch wrote:
On Fri, 9 Oct 2009, Philip J�genstedt wrote:
Since we're going to contradict the progress events spec anyway, I
would suggest dropping all 'loadend' events. They're just
From: Ian Hickson
Anyway, Perhaps this will do?
If a transparent element were to be removed but its descendants were
kept as they are, the content should remain conformant.
Or:
Any transparent content should be conformant as if its transparent
containing element did not
On Wed, Oct 14, 2009 at 8:17 AM, Yuvalik Webdesign
postmas...@yuvalik.org wrote:
From: Ian Hickson
Anyway, Perhaps this will do?
If a transparent element were to be removed but its descendants were
kept as they are, the content should remain conformant.
Or:
Any transparent
From: Tab Atkins Jr.
Perhaps you could leave the existing sentence, but add:
In short; a transparent element must have the same content model as
its parent.
Or something to that effect?
That's still not accurate, though. ^_^ I mean, it's *correct*, but
it's not a summarization
Hixie wrote:
Then it might be nice to clarify this with a few words
in the spec, as The fieldset element represents a set of form
controls
optionally grouped under a common name can be read as implying
structuring and thus accessibility matters.
The element does add structure and help with
On Wed, Oct 14, 2009 at 10:32 AM, Jeremy Keith jer...@adactio.com wrote:
Hixie wrote:
Then it might be nice to clarify this with a few words
in the spec, as The fieldset element represents a set of form controls
optionally grouped under a common name can be read as implying
structuring and
Rimantas,
Maybe there are not many sites because nobody wants this type of sites?
You think nobody wants Javadoc? Javadoc has been shipping with an
read-only version of this use case for years.
The full use case is treeview database maintenance. Tree logic has been
slow to mature in SQL, is
On Wed, Oct 14, 2009 at 11:56 AM, Peter Brawley p...@artfulsoftware.com wrote:
Correct, but excluding frameset from HTML5 increases the likelihood that
browsers will drop support for the feature.
The spec requires all browsers to support framesets. Look:
Maybe there are not many sites because nobody wants this type of sites?
You think nobody wants Javadoc? Javadoc has been shipping with an read-only
version of this use case for years.
Of course Java developers want access to documentation. I am not sure
if they want frameset though.
The full
On 14 Oct 2009, at 17:12, Rimantas Liubertas wrote:
Maybe there are not many sites because nobody wants this type of
sites?
You think nobody wants Javadoc? Javadoc has been shipping with an
read-only
version of this use case for years.
Of course Java developers want access to
On Wed, Oct 14, 2009 at 8:56 AM, Peter Brawley p...@artfulsoftware.com wrote:
Nobody forbids you from using previous versions of HTML.
Correct, but excluding frameset from HTML5 increases the likelihood that
browsers will drop support for the feature.
As a browser developer, and as someone
On Wed, Oct 14, 2009 at 11:51 PM, Philip Jägenstedt phil...@opera.comwrote:
We added loadend just to comply with Progress Events. Now that we fire
simple events instead, please drop loadend again as it serves no purpose at
all. I doubt any browser has yet shipped an implementation firing
13.10.2009, в 4:11, Ian Hickson написал(а):
Is this meant to mimic some behavior that existing clients have for
HTTP
already?
Yes, as it says, the idea is for UAs to send the same headers they
would
send if the protocol had been HTTP.
For HTTP, this depends on authentication scheme in
PB,
No matter what display method you use, it sounds like an important
requirement is to keep users from ever viewing the HTML of a row other
than from your display app/page. It seems to me to achieve this you
must not use URIs alone to fetch the row view that goes in the row's
frame, because
On Wed, Oct 14, 2009 at 4:38 PM, Michael Enright
michael.enri...@gmail.com wrote:
No matter what display method you use, it sounds like an important
requirement is to keep users from ever viewing the HTML of a row other
than from your display app/page. It seems to me to achieve this you
must
Aryeh Gregor schrieb:
On Wed, Oct 14, 2009 at 11:56 AM, Peter Brawley p...@artfulsoftware.com wrote:
Correct, but excluding frameset from HTML5 increases the likelihood that
browsers will drop support for the feature.
The spec requires all browsers to support framesets. Look:
36 matches
Mail list logo
