Re: [whatwg] updateWithSanitizedHTML (was Re: innerStaticHTML)
Your main point is well taken. There are some technical reasons why tag whitelisting makes more sense for inline content. For example, consider the case you mentioned on webkit-dev: @id. Inline, @id is problematic because the ids exist in a per-frame namespace, whereas they're harmless when the untrusted content has an entire iframe to itself. Of course, @id is not unique in this respect. For example, input type=password will likely get autofilled by the password manager inline and @style can be used to draw all over the page without an iframe's layout contraints. That said, I'm not married to a design with a tag-level whitelist. Do you have a specific alternative in mind? Adam On Mon, Nov 30, 2009 at 7:43 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 30, 2009, at 6:32 PM, Adam Barth wrote: On Mon, Nov 30, 2009 at 5:43 PM, Maciej Stachowiak m...@apple.com wrote: 1) It seems like this API is harder to use than a sandboxed iframe. To use it correctly, you need to determine a whitelist of safe elements and attributes; providing an explicit whitelist at least of tags is mandatory. With a sandboxed iframe, as a Web developer you can just ask the browser to turn off unsafe things and not worry about designing a security policy. Besides ease of use, there is also the concern that a server-side filtering whitelist may be buggy, and if you apply the same whitelist on the client side as backup instead of doing something high level like disable scripting then you are less likely to benefit from defense in depth, since you may just replicate the bug. I should follow up with folks in the ruby-on-rails community to see how they view their sanitize API. The one person I asked had a positive opinion, but we should get a bigger sample size. For server-side sanitization, this kind of explicit API is pretty much the only thing you can do. I think updateWithSanitizedHTML has different use cases than @sandbox. I think the killer applications for @sandbox are advertisements and gadgets. In those cases, the developer wants most of the browser's functionality, but wants to turn off some dangerous stuff (like plug-ins). For updateWithSanitizedHTML, the killer application is something like blog comments, where you basically want text with some formatting tags (bold, italics, and maybe images depending on the forum). I can imagine use cases where allowing very open-ended but script-free content is desirable. For example, consider a hosted blog service that wants to let blog authors write nearly arbitrary HTML, but without allowing script. @sandbox would not be a good solution for that use case. In general it does not seem sensible to me that the choice of tag whitelisting vs high-level feature whitelisting is tied to the choice of embedding content directly vs. creating a frame. Is there a technical reason these two choices have to be tied? 2) It seems like this API loses one of the big benefits of sanitizing HTML in the browser implementation. Specifically, in theory it's safe to say allow everything except any construct that would result in script/code running. You can't do that on the server side - blacklisting is not sound because you can't predict the capabilities of all browsers. But the browser can predict its own capabilities. Sandboxed iframes do allow for this. The benefit is that you know you're getting the right parsing. You're not going to be tripped up by img/src=javascript: and friends. It's true, this is a benefit. However, it seems like even if you whitelist tags, being able to say no script at a high level Also, this API is useful in cases where you don't have a server to help you sanitize your input. One example I saw recently was a GreaseMonkey script that wanted to add EXIF metadata to Flickr. Basically, the script grabbed the EXIF data from api.flickr.com and added it to the current page. Unfortunately, that meant I could use this GreaseMonkey script to XSS Flickr by adding HTML to my EXIF metadata. Sure, there are other ways of solving the problem (I asked the developer to build the DOM in memory and use innerText), but you want something simple for these cases. If the EXIF metadata is supposed to be text-only, it seems like updateWithSanitizedHTML would not be easier to use than innerText, or in any way superior. For cases where it is actually desirable to allow some markup, it's not clear to me that giving explicit whitelists of what is allowed is the simple choice. I think the benefits of filtering by tag/attribute/scheme for advanced experts are outweighed by these two disadvantages for basic use, compared to something simple like the original staticInnerHTML idea. Another possible alternative is to express how to sanitize at a higher level, using something similar to sandboxed iframe feature strings. If you think of @sandbox as being optimized for rich untrusted content and
Re: [whatwg] Web Workers: Worker.onmessage
On Wed, 11 Nov 2009, Simon Pieters wrote: On Wed, 11 Nov 2009 16:05:53 +0100, Simon Pieters sim...@opera.com wrote: Shouldn't setting onmessage on a Worker object enable the port message queue? Currently step 8 of the run a worker algorithm enables the port message queue for the WorkerGlobalObjectScope side, but it is never enabled when going in the other direction, if I'm reading the spec correctly. Hmm. Actually, step 12 and 13 of the Worker constructor enable the port message queue for both the inside and outside ports. Why does the run a worker algorithm enable one of them again? Isn't it too early to enable the port message queues before the worker has run and set 'onmessage'? I suppose that if the worker is slow to start up, it could conceivably receive a message before the event loop exists, which would lead to poorly defined behaviour. I've removed the inner port opening from the constructor's algorithm. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Web workers] An attribute describing the best number of worker to invoke in a delegation use case
On Wed, 11 Nov 2009, David Bruant wrote: This is a new proposal taking into account the feedback I recieved to the [WebWorkers] About the delegation example message. In the delegation example of the WebWorker spec, we can see this line : var num_workers = 10; My concern is about the arbitrarity of the 10. I agree that it's suboptimal. However, I think realistically a good implementation of parallel work would need some sort of dynamic performance tuning, continuously slowly ramping up the number of workers while it increases throughput, and when throughput decreases, switching to reducing the number of workers until throughput increases again. That would probably be too complicated to show in an example in the spec. My proposal is to add an attribute to the navigator object to write this : var num_workers = navigator.optimalWorkerNumber; var items_per_worker = 1000/num_workers; (uneven dividing can easily be solved) (the name optimalWorkerNumber is not good, but I will use it in the rest of this e-mail) optimalWorkerNumber is a function of time and of the algorithm that the worker implements. I don't think it would solve the problem. This attribute have the following properties : - It's only dependant on the hardware, the operating system and the WebWorker implementation (thus, it is not dynamically computed by the user agent at each call and two calls in the same hardware//OS//WebWorker implementation have the same result). - In the same running conditions (same memory available, same number of process running concurrently...) running the same algorithm (an easy delegation algorithm) has a significantly better performance with (navigator.optimalWorkerNumber) workers than (navigator.optimalWorkerNumber - 1) workers - In the same running conditions, running the same algorithm has no significantly better performance with (navigator.optimalWorkerNumber +1) workers than (navigator.optimalWorkerNumber) workers I do not think it is possible to satisfy all of the above conditions at the same time. On Thu, 12 Nov 2009, David Bruant wrote, in response to Boris saying much the same as what I wrote above: = You're perfectly right. I reformulate the definition of running conditions (appearing in condition 2 and 3) as : same memory available, same number of process running concurrently, no other worker running working on the same document. On Thu, 12 Nov 2009, Boris Zbarsky wrote: That doesn't help that much, unfortunately. Most simply, consider a quad-core chip and workers that are completely cpu-bound. If there are no other processes running, the optimal number of workers is 4. If there is one other process which is also completely cpu-bound running, the optimal number of workers is 3 (in the sense that 4 may well not satisfy your condition 3). This is really the same issue as having one worker running, but it's some process not under the browser's control. If, on the other hand, the workers are I/O bound (esp. network I/O latency bound), then the optimal number of workers can well be larger than the number of cores... On Thu, 12 Nov 2009, David Bruant wrote: = If you are comparing no other processes running and one other process which is also completely cpu-bound running, you are not in what I've called same running conditions. (because the number of concurrent processes is different). The point is that the constant can't be constant if it has to return a different number based on conditions outside the UA's control. I reformulate this way the conditions 2 and 3: - In blank conditions (no other processes/thread running on the CPU, enough memory to allocate the workers), running the same algorithm (an easy delegation algorithm) has significantly better performances with (navigator.optimalWorkerNumber) dedicated workers than with (navigator.optimalWorkerNumber -1) dedicated workers - In blank conditions, running the same algorithm has no significantly better performances with (navigator.optimalWorkerNumber+1) dedicated workers than with (navigator.optimalWorkerNumber) dedicated workers This isn't especially useful, since blank conditions are never met by a running script (for one, the script is running). Just to remind, the purpose of this attribute is to decide, at the beginning of a delegation algorithm what is the optimal number of workers to divide the work in a way that is optimal regarding the hardware, the OS and the worker implementation. No matter the running conditions, 2 calls return the same value for the same hardware//OS//Worker implementation. The idea behind this property is that even if you start running the algorithm with a lot of concurrent processes, you create a number of workers that cannot be ran concurrently at the beginning, but you may use optimally the ressources later (if the other processes/threads stop running, what you cannot control, but can still hope that it happens
Re: [whatwg] updateWithSanitizedHTML (was Re: innerStaticHTML)
The WebKit community is considering taking up such an experimental implementation. Here's my current proposal for how this might work: http://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTJzbTY1cWJrNAhl=en I would appreciate any feedback on the design. Whitelist requires developers to know about potential risks of each element/property, and that's not obvious to everyone: e.g. one might want to allow object/embed (for harmless YouTube videos) without realizing that it enables XSS. It's also non-obvious that style attribute is XSS risk (via behavior property). Higher-level filtering option could allow style attribute, and only filter out that property. Current proposal would need another whitelist for CSS properties. And even whitelist for CSS properties couldn't be used to implement No external access policy (allow images with data: urls, allow http: links, but not http: images). This would be useful for webmails and other places where website doesn't want to allow 3rd parties tracking views. No clickjacking option might be useful as well. -- regards, Kornel Lesiński
Re: [whatwg] figureimg* caption
Philip Jägenstedt wrote: As currently speced, the proper usage of figure is: figure ddimg src=bunny.jpg alt=A Bunny/dd dtThe Cutest Animal/dt /figure Apart from all that has been said about legacy parsing, leaking style in IE, etc I would (perhaps not be the first to) add: 1. It seems quite easy to confuse or mistype dd/dt. Without guessing how often authors will get it wrong, I think everyone agrees that (all else equal) a syntax which is harder to confuse/mistype is better. Yes, I expect we'll see a lot of authors get them reversed, using the dd for the caption if they want the caption below the content. This is likely to occur since existing authors have already learned that dt comes before dd when used within a dl, and because old habbits die hard, they're likely to repeat the pattern within figure. 2. Only the caption needs to be marked up, the content is implicitly everything else. While some content may need a wrapping element for styling, e.g. img usually does not. 3. Aesthetics. (My eyes are bleeding, but I can't speak for anyone else's.) Some additional reasons why using dt/dd in figure is a bad solution: The simplest workaround presented so far to solve the styling issue in IE is basically to do this: div class=figure figure ddimg src=image alt=.../dd dtCaption/dt /figure /div And then rather than style the figure itself, give some style to the div because some styles don't work properly when applied to the figure. This effectively makes the figure element itself entirely useless, especially given that all browsers lack support for it. It would be far easier for authors to just stick with this entirely hack free alternative that doesn't use the new elements: div class=figure img src=image alt=... p class=captionCaption/p /div At least until browsers actually implement support for figure and IE6/7's market share becomes negligible. It will take a couple of years for those events to occur, and there's no need to rush into using the new elements yet. The main difficulty with coming up with something better seems to have been finding a name for an element which isn't already taken. If that's the only issue, why not just take some inspiration from time pubdate and use an attribute instead? figure img src=bunny.jpg alt=A Bunny p captionThe Cutest Animal/p /figure I was the first one to suggest that on IRC a while ago, but I'm not convinced it's a good idea. Although it's certainly better than using dt/dd. See IRC logs here. http://krijnhoetmer.nl/irc-logs/whatwg/20090917#l-1525 http://krijnhoetmer.nl/irc-logs/whatwg/20090918#l-1133 The original idea for using the attribute was that it could apply to a wide range of elements, like p, div, etc. But that makes it difficult for browsers to provide sensible default styling for captions, since it requires carefully overriding existing defaults for so many other elements. To some extent, it even makes it difficult for authors to provide reasonable styles if they can't guarantee which elements content writers will choose for their caption. Imagine designing a CMS template with some default styles for figure and caption, the CSS in the template would have to deal with so many possible element choices just for the caption, it'll be difficult to get it right and test everything. Limiting the caption attribute to just the p element, or just div or something, might help, but I'd still expect authors to end up using it on other elements anyway. There are only 2 sensible options for element choices: legend or introducing a new element. Using dt/dd is *not* and was never a sensible choice for figure, and the idea must be dropped. Since Hixie is adamant that introducing a new element for the caption isn't going to happen, and I've yet to find a way to convince him otherwise, that leaves us with legend. Although legend has it's own styling issues in browsers, these will eventually be resolved in a couple of years. Therefore, the best solution is to revert the spec back to using legend for figure, but strongly discourage authors from using these new elements yet, until the implementation issues are resolved. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] figureimg* caption
The original idea for using the attribute was that it could apply to a wide range of elements, like p, div, etc. But that makes it difficult for browsers to provide sensible default styling for captions, since it requires carefully overriding existing defaults for so many other elements. To some extent, it even makes it difficult for authors to provide reasonable styles if they can't guarantee which elements content writers will choose for their caption. Imagine designing a CMS template with some default styles for figure and caption, the CSS in the template would have to deal with so many possible element choices just for the caption, it'll be difficult to get it right and test everything. This does make sense. Would be really hard, for sure. There are only 2 sensible options for element choices: legend or introducing a new element. Using dt/dd is *not* and was never a sensible choice for figure, and the idea must be dropped. As caption and legend have much too many backwards compatibility issues, the only possible solution is either a new element or dropping the whole figure-thing. The second thing should really be taken into account. Better no syntax than bad syntax :) What tag-titles could be used to mark the captions up? I thought of desc or description (first is better). Does not seem to be taken, but I don't know whether it is as intuitive. (But I as a German, who can't speak English very well, would search for html5 image description next after html5 caption.) MfG Nikita Popov
Re: [whatwg] figureimg* caption
On Tue, Dec 1, 2009 at 7:28 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: To some extent, it even makes it difficult for authors to provide reasonable styles if they can't guarantee which elements content writers will choose for their caption. Imagine designing a CMS template with some default styles for figure and caption, the CSS in the template would have to deal with so many possible element choices just for the caption, it'll be difficult to get it right and test everything. There are a multitude of reset style sheets on the web today that don't seem to have a problem removing virtually all default styling from elements. It would not be difficult to modify one to strip a @caption element down to bare bones and then restyle as desired. ~TJ
Re: [whatwg] figureimg* caption
On Tue, 01 Dec 2009 15:33:28 +0100, Nikita Popov pri...@ni-po.com wrote: There are only 2 sensible options for element choices: legend or introducing a new element. Using dt/dd is *not* and was never a sensible choice for figure, and the idea must be dropped. As caption and legend have much too many backwards compatibility issues, the only possible solution is either a new element or dropping the whole figure-thing. or a new attribute -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] updateWithSanitizedHTML (was Re: innerStaticHTML)
2009/12/1 Kornel Lesiński kor...@geekhood.net: The WebKit community is considering taking up such an experimental implementation. Here's my current proposal for how this might work: http://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTJzbTY1cWJrNAhl=en I would appreciate any feedback on the design. Whitelist requires developers to know about potential risks of each element/property, and that's not obvious to everyone: e.g. one might want to allow object/embed (for harmless YouTube videos) without realizing that it enables XSS. That's true. It would be interesting to know how often developers screw this up with Ruby-on-Rails' version of the API. It's also non-obvious that style attribute is XSS risk (via behavior property). Higher-level filtering option could allow style attribute, and only filter out that property. Current proposal would need another whitelist for CSS properties. Script-in-CSS is subtle enough that it's explicitly blocked (like javascript URLs). And even whitelist for CSS properties couldn't be used to implement No external access policy (allow images with data: urls, allow http: links, but not http: images). This would be useful for webmails and other places where website doesn't want to allow 3rd parties tracking views. I don't think an no external access policy is worth supporting explicitly. If it falls out of a general design, that's great, but I don't think the use case is compelling enough to accept the design constraints required to support it. No clickjacking option might be useful as well. I don't have a clear idea how this would work. Did you have something different in mind than X-Frame-Options (already supported by WebKit)? Adam
Re: [whatwg] figureimg* caption
Tab Atkins Jr. wrote:
On Tue, Dec 1, 2009 at 7:28 AM, Lachlan Huntlachlan.h...@lachy.id.au wrote:
To some extent, it even makes it difficult for authors to provide reasonable
styles if they can't guarantee which elements content writers will choose
for their caption. Imagine designing a CMS template with some default
styles for figure and caption, the CSS in the template would have to deal
with so many possible element choices just for the caption, it'll be
difficult to get it right and test everything.
There are a multitude of reset style sheets on the web today that
don't seem to have a problem removing virtually all default styling
from elements. It would not be difficult to modify one to strip a
@caption element down to bare bones and then restyle as desired.
Applying reset styles alone and making all elements look the same
basically defeats the purpose of being able to use a range of different
elements, and is very likely not what an author would ultimately want.
Reset styles are just used to give different elements a more level
playing field for new styles, and so authors would then still have to go
through all the elements and style them appropriately for use as a
caption. Plus, authors have to worry about cascading issues from other
styles in their own stylesheets.
Say, for instance, an author had applied special styles to paragraphs in
some special type of section:
#foo p { margin-left: 1em; }
And then a content writer puts a figure in there using p caption, but
the CSS author failed to adequately account for figures being used in
that section, despite doing:
p[caption] { margin: 0; }
Due to specificity, the first rule would apply regardless and the
caption would get a potentially unwanted margin.
I know there are ways to work around the issue, such as using !important
or finding ways to increase the specificity of the latter selector, but
the point is that introducing unnecessary element clashes creates
needless complexities that should be avoided.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] figureimg* caption
On Tue, Dec 1, 2009 at 9:07 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
Applying reset styles alone and making all elements look the same basically
defeats the purpose of being able to use a range of different elements, and
is very likely not what an author would ultimately want.
Heh, you either want consistent styling, in which case you use a
reset, or you want element-specific styling, in which you don't.
Can't have it both ways. ^_^
Reset styles are just used to give different elements a more level playing
field for new styles, and so authors would then still have to go through all
the elements and style them appropriately for use as a caption. Plus,
authors have to worry about cascading issues from other styles in their own
stylesheets.
Say, for instance, an author had applied special styles to paragraphs in
some special type of section:
#foo p { margin-left: 1em; }
And then a content writer puts a figure in there using p caption, but the
CSS author failed to adequately account for figures being used in that
section, despite doing:
p[caption] { margin: 0; }
Due to specificity, the first rule would apply regardless and the caption
would get a potentially unwanted margin.
I know there are ways to work around the issue, such as using !important or
finding ways to increase the specificity of the latter selector, but the
point is that introducing unnecessary element clashes creates needless
complexities that should be avoided.
This is a valid complaint.
~TJ
Re: [whatwg] figureimg* caption
On 1 Dec 2009, at 14:33, Nikita Popov wrote: As caption and legend have much too many backwards compatibility issues It's not bad I think. I've played a little with the live DOM viewer and this seems usable: figure content captiondiv class=captionfoo/div/caption /figure caption start/end tag is completely ignored, so at lest there's no negative side effect. You only need another styling hook. It's not any worse than suggested hack for dd. To ease transition, HTML5 might allow wrapping caption in table without any rows: figure content tablecaptionfoo/caption/table /figure This gives good DOM and styling in all browsers (with createElement hack in IE of course). This caption can be styled differently from real table captions using caption:only-child selector. Saying that caption of table in figure is also figure's caption IMHO makes sense even for real tables (is there a need for doubly-captioned figure-table?) -- regards, Kornel
Re: [whatwg] figureimg* caption
On Tue, 01 Dec 2009 14:28:32 +0100, Lachlan Hunt
lachlan.h...@lachy.id.au wrote:
Philip Jägenstedt wrote:
As currently speced, the proper usage of figure is:
figure
ddimg src=bunny.jpg alt=A Bunny/dd
dtThe Cutest Animal/dt
/figure
Apart from all that has been said about legacy parsing, leaking style in
IE, etc I would (perhaps not be the first to) add:
1. It seems quite easy to confuse or mistype dd/dt. Without guessing how
often authors will get it wrong, I think everyone agrees that (all else
equal) a syntax which is harder to confuse/mistype is better.
Yes, I expect we'll see a lot of authors get them reversed, using the dd
for the caption if they want the caption below the content. This is
likely to occur since existing authors have already learned that dt
comes before dd when used within a dl, and because old habbits die hard,
they're likely to repeat the pattern within figure.
2. Only the caption needs to be marked up, the content is implicitly
everything else. While some content may need a wrapping element for
styling, e.g. img usually does not.
3. Aesthetics. (My eyes are bleeding, but I can't speak for anyone
else's.)
Some additional reasons why using dt/dd in figure is a bad solution:
The simplest workaround presented so far to solve the styling issue in
IE is basically to do this:
div class=figure
figure
ddimg src=image alt=.../dd
dtCaption/dt
/figure
/div
And then rather than style the figure itself, give some style to the div
because some styles don't work properly when applied to the figure. This
effectively makes the figure element itself entirely useless, especially
given that all browsers lack support for it.
It would be far easier for authors to just stick with this entirely hack
free alternative that doesn't use the new elements:
div class=figure
img src=image alt=...
p class=captionCaption/p
/div
At least until browsers actually implement support for figure and
IE6/7's market share becomes negligible. It will take a couple of years
for those events to occur, and there's no need to rush into using the
new elements yet.
The main difficulty with coming up with something better seems to have
been finding a name for an element which isn't already taken. If that's
the only issue, why not just take some inspiration from time pubdate
and use an attribute instead?
figure
img src=bunny.jpg alt=A Bunny
p captionThe Cutest Animal/p
/figure
I was the first one to suggest that on IRC a while ago, but I'm not
convinced it's a good idea. Although it's certainly better than using
dt/dd.
See IRC logs here.
http://krijnhoetmer.nl/irc-logs/whatwg/20090917#l-1525
http://krijnhoetmer.nl/irc-logs/whatwg/20090918#l-1133
The original idea for using the attribute was that it could apply to a
wide range of elements, like p, div, etc. But that makes it difficult
for browsers to provide sensible default styling for captions, since it
requires carefully overriding existing defaults for so many other
elements.
You only need to provide styles for the elements you're using which
wouldn't work with a simple generic style such as.
figure[caption] { margin-left: 1em; font-weight: bold; }
Please, no examples where this doesn't work. It's obvious, but also very
easy to fix.
To some extent, it even makes it difficult for authors to provide
reasonable styles if they can't guarantee which elements content writers
will choose for their caption. Imagine designing a CMS template with
some default styles for figure and caption, the CSS in the template
would have to deal with so many possible element choices just for the
caption, it'll be difficult to get it right and test everything.
Imaginary template language:
figure
@content@
div caption@caption@/div
/figure
Does everything you could do with a new element. Almost everyone else will
probably get by without wrapping divs though.
Limiting the caption attribute to just the p element, or just div or
something, might help, but I'd still expect authors to end up using it
on other elements anyway.
There are only 2 sensible options for element choices: legend or
introducing a new element. Using dt/dd is *not* and was never a
sensible choice for figure, and the idea must be dropped.
Since Hixie is adamant that introducing a new element for the caption
isn't going to happen, and I've yet to find a way to convince him
otherwise, that leaves us with legend.
Although legend has it's own styling issues in browsers, these will
eventually be resolved in a couple of years. Therefore, the best
solution is to revert the spec back to using legend for figure, but
strongly discourage authors from using these new elements yet, until the
implementation issues are resolved.
If all of the ideas are rejected I agree that it would be better to drop
figure, but I hope it won't come to that. A pointer to any parsing/styling
issues of legend
Re: [whatwg] figureimg* caption
On Tue, 01 Dec 2009 16:36:08 +0100, Philip Jägenstedt phil...@opera.com
wrote:
You only need to provide styles for the elements you're using which
wouldn't work with a simple generic style such as.
figure[caption] { margin-left: 1em; font-weight: bold; }
Please, no examples where this doesn't work. It's obvious, but also very
easy to fix.
Sent too early... this part is about author styles. I don't think there
should be a default browser style at all.
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] updateWithSanitizedHTML (was Re: innerStaticHTML)
And even whitelist for CSS properties couldn't be used to implement No external access policy (allow images with data: urls, allow http: links, but not http: images). This would be useful for webmails and other places where website doesn't want to allow 3rd parties tracking views. I don't think an no external access policy is worth supporting explicitly. If it falls out of a general design, that's great, but I don't think the use case is compelling enough to accept the design constraints required to support it. I think it is quite important for privacy. Otherwise web bugs can be placed and used to track every use of content in every mashup. Most often I'd like formatted text in applications to be just text, _completely_ passive. No clickjacking option might be useful as well. I don't have a clear idea how this would work. Did you have something different in mind than X-Frame-Options (already supported by WebKit)? On a second thought clickjacking is probably not the right term for what I have in mind, although it's a similar issue. The problem is that content added in DOM could use styles to overlay web application's chrome and steal data with forms or redirect standard links/buttons to phising site, e.g. form action=evil style=position:fixed; top:0; right:0 that's positioned on top of website's standard login form. Position:fixed escapes elements with position:relative;overflow:hidden, so AFAIK this cannot be prevented without removal of all position:fixed styles from untrusted content. Such hack has been used on auction site allegro.pl, where auctions' descriptions are allowed to use CSS. In that particular case content should have been filtered server-side, but I imagine webmails, web- based feed readers and all kinds of mashups dynamically loading untrusted content could face similar problems, and having iframe for every bit of content is sometimes problematic. -- regards, Kornel
Re: [whatwg] updateWithSanitizedHTML (was Re: innerStaticHTML)
2009/12/1 Kornel Lesiński kor...@geekhood.net: And even whitelist for CSS properties couldn't be used to implement No external access policy (allow images with data: urls, allow http: links, but not http: images). This would be useful for webmails and other places where website doesn't want to allow 3rd parties tracking views. I don't think an no external access policy is worth supporting explicitly. If it falls out of a general design, that's great, but I don't think the use case is compelling enough to accept the design constraints required to support it. I think it is quite important for privacy. Otherwise web bugs can be placed and used to track every use of content in every mashup. Most often I'd like formatted text in applications to be just text, _completely_ passive. I agree that it's a nice benefit of some designs, but, in my opinion, it's not nearly as important as addressing the security issues. More concretely, suppose you want to let folks include hyperlinks in sanitized HTML, which I suspect many people will want to do. You've already lost the battle against web bugs because of DNS prefetch. No clickjacking option might be useful as well. I don't have a clear idea how this would work. Did you have something different in mind than X-Frame-Options (already supported by WebKit)? On a second thought clickjacking is probably not the right term for what I have in mind, although it's a similar issue. The problem is that content added in DOM could use styles to overlay web application's chrome and steal data with forms or redirect standard links/buttons to phising site, e.g. form action=evil style=position:fixed; top:0; right:0 that's positioned on top of website's standard login form. Position:fixed escapes elements with position:relative;overflow:hidden, so AFAIK this cannot be prevented without removal of all position:fixed styles from untrusted content. Such hack has been used on auction site allegro.pl, where auctions' descriptions are allowed to use CSS. In that particular case content should have been filtered server-side, but I imagine webmails, web-based feed readers and all kinds of mashups dynamically loading untrusted content could face similar problems, and having iframe for every bit of content is sometimes problematic. I agree that this is a threat worth addressing. That's one reason why an API that blocks only script is insufficient for inline use cases. Notice that my proposal does mitigate this threat. Adam
Re: [whatwg] figureimg* caption
Is there a reason we can't reuse legend (or label)? I don't think giving p an attribute that it can only use inside of figure is very straightforward.
Re: [whatwg] figureimg* caption
On Tue, Dec 1, 2009 at 6:01 PM, Hugh Guiney hugh.gui...@gmail.com wrote: Is there a reason we can't reuse legend (or label)? I don't think giving p an attribute that it can only use inside of figure is very straightforward. Yes. legend is documented as having rendering issues in all current browsers if placed outside of a fieldset (for example, in some browsers it will *generate a fieldset* around itself). label doesn't have appropriate keyboard accessibility when used for details. The @caption proposal isn't for an attribute on p only, but rather for an attribute on any element that is a child of a figure. (It's just that most of the time using a p is most appropriate.) ~TJ
Re: [whatwg] [WebWorkers] Advocation to provide the DOM API to the workers
On Thu, 12 Nov 2009, David Bruant wrote: I was waiting for Firefox to stop freezing on the HTML5 spec page (it freezes about one minute each time I visit the one-page version) and I tried to think of a way to design this page in a way that wouldn't freeze my browser. The easiest way is to disable the scripts, which you can do by appending ?slow-browser to the page's URL, as in: http://www.whatwg.org/specs/web-apps/current-work/?slow-browser One good way I have found would be to cut the whole page into several parts (one the server side, what is already done in the multi-page version) and to launch several workers. Each worker gets one part of the whole page in the background and could give it to the browsing context which will append the right part at the right place. As others have noted, the slowness turns out to not be parsing, but to be a bunch of scripts that are doing various things such as adding the sidebar annotations, setting up the dfn cross-references, and generating the short table of contents. Plus, since browsers don't have thread-safe DOM implementations, we actually can't expose the DOM in workers. Maybe one day. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] figureimg* caption
On Dec 1, 2009, at 4:08 PM, Tab Atkins Jr. wrote: On Tue, Dec 1, 2009 at 6:01 PM, Hugh Guiney hugh.gui...@gmail.com wrote: Is there a reason we can't reuse legend (or label)? I don't think giving p an attribute that it can only use inside of figure is very straightforward. Yes. legend is documented as having rendering issues in all current browsers if placed outside of a fieldset (for example, in some browsers it will *generate a fieldset* around itself). label doesn't have appropriate keyboard accessibility when used for details. It's not just rendering issues - all current browsers produce a broken DOM when you include legend outside of fieldset, ranging from dropping the legend element entirely to creating a fieldset to doing the IE thing of adding void elements named legend and /legend (but without the usual script workaround. I don't think keyboard accessibility is a problem for label. details itself can be made focusable. I believe the only technical issues with label are: 1) Some sites already have style rules for label based on the assumption that it is only ever used for form labels. So they would have to tweak their CSS to be able to use details. I don't think this argument is very strong. 2) Using label could create issues in present-day browsers if the label includes a form control. Specifically the label would be considered the label of the form control if it has no other label, which may not be appropriate. This is somewhat unlikely but not altogether impossible. Opinions on the seriousness of these two issues vary, but I must concede that the dt/dd solution does not have these two specific problems. BTW the current alternate proposal in the HTML Working Group is to replace dt/dd with a fltcap element to use as the label for both figure and details: http://esw.w3.org/topic/HTML/ChangeProposals/DdDt . Regards, Maciej
Re: [whatwg] Interface objects in Web Workers
On Wed, 25 Nov 2009, Simon Pieters wrote: The Interface objects and constructors section says There must be no interface objects and constructors available in the global scope of scripts whose script's global object is a WorkerGlobalScope object except for the following: WorkerGlobalScope, WorkerLocation, Navigator, AbstractWorker, ErrorEvent are not in the list. Is this intentional? If they're intended to not create interface objects, it would be clearer if the IDLs had [NoInterfaceObject]. I've changed that section to be more precise legalese that automatically does the right thing. Should EventTarget and Event be in the list? These are now automatically covered by the new magical text in the aforementioned section. (Basically I said that any interfaces relevant to exposed APIs are automatically to be available.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] createEvent() in Web Workers?
On Thu, 26 Nov 2009, Simon Pieters wrote: There's ErrorEvent.initErrorEvent, and dispatchEvent is exposed in workers, but there's no createEvent (because there's no document). Are there use cases for sending events in a worker? Should we expose createEvent somewhere? Should we remove initErrorEvent? I don't want to remove initErrorEvent() because that would just cause troubles later if we ever add createEvent(). In the meantime, though, I don't see a really compelling reason to add event creation to the worker API set, so I haven't changed anything there for now. If DOM3 Events adds constructors or whatever, it can expose them to Workers easily enough. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
