I am unsure if this applies to HTML (or rather CSS). From the archives I see
that Dean Edwards proposed some reset/reset element that was supposed to
reset styles to the page default style. I have another proposal
div style='inherit: nothing'/div
This would effectively make everything inside the
On Tue, 17 Jun 2008 12:43:32 +0200, Frode Børli [EMAIL PROTECTED] wrote:
I am unsure if this applies to HTML (or rather CSS). From the archives I
see that Dean Edwards proposed some reset/reset element that was
supposed to reset styles to the page default style. I have another
proposal
On Tue, 17 Jun 2008 06:09:55 +0200, Frode Børli [EMAIL PROTECTED] wrote:
Hi! I am a new member of this mailing list, and I wish to contribute
with a couple of specific requirements that I believe should be
discussed and
perhaps implemented in the final specification. I am unsure if this is
I have been reading up on past discussions on sandboxing content, and
I feel that it is generally agreed on that there should be some
mechanism for marking content as user generated. The discussion
mainly appears to be focused on implementation. Please read my
implementation notes at the end of
1. Please elaborate how an extension of CSS would require a sanitizer
update.
2. Please explain why using a dedicated tag with double parsing is easier
for a Web developer than putting the code in an attribute.
3. Your quoting solution would not cause legacy browsers to show plain
text; they
Hello,
I'm new to the list and have joined in response to this discussion on
html security changes.
I have been reading up on past discussions on sandboxing content, and I feel
that it is generally agreed on that there should be some mechanism for
marking content as user
generated. The
I've also been having side discussions with a few people regarding the
ability for a website owner to mark sections as data rather than code
(where everything lies now).
Your htmlarea tag idea is a good one (maybe change the tag to data
just a nitpick) however you don't address the use case
1. Please elaborate how an extension of CSS would require a sanitizer
update.
In the year 1998: A sanitizer algorithm works perfectly for all
existing methods of adding scripts. It uses a white list, which allows
only certain tags and attributes. Among the allowed attributes is
colspan,
Frode Børli wrote:
I have been reading up on past discussions on sandboxing content, and
I feel that it is generally agreed on that there should be some
mechanism for marking content as user generated. The discussion
mainly appears to be focused on implementation. Please read my
implementation
This particular explanation is irrelevant to the topic because sandboxed
fragments can contain scripts, whether within CSS or not. The idea of
sandboxing is to disable scripts, not to purge them.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
I have been reading up on past discussions on sandboxing content, and
I feel that it is generally agreed on that there should be some
mechanism for marking content as user generated. The discussion
mainly appears to be focused on implementation. Please read my
implementation notes at the end
The problem with tag warning is, if /data is the first token inserted,
there will be no warning because the resulting code will be valid. So the
key question remains: how do you tell unescaped /data from the closing
/data? And the warning, if applicable, will go to the wrong person: to
all
Hello,
We've had a number of discussions in the #whatwg channel thus far about the
TCPConnection specification in section 6, and the consesus is that there is
utility in an asynchronous, bi-directional communication mechanism, but the
current proposal has a number of issues that need to be
ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.
I understand the reasoning but I do not believe this should be limited
to ports 80 and 443. By doing so we render the protocol difficult to use
as many (if not most) custom services would need to run on another port
to avoid
On Wed, 18 Jun 2008, Shannon wrote:
ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.
I understand the reasoning but I do not believe this should be limited
to ports 80 and 443.
You misunderstand; it's not the ports that are limited, it's just that the
traffic can now pass for
15 matches
Mail list logo
