Re: [whatwg] Safari-compatible
Binoculars are more appropriate because they can be used to look around whereas a magnifying glass cannot. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christoph Päper Sent: Tuesday, September 30, 2008 11:55 PM To: WHAT working group Subject: Re: [whatwg] Safari-compatible The magnifying glass was a particularly poor choice by Apple[1], because icons featuring one usually represent zooming (in). Binoculars are (for some reason) more common as symbols for searches. Eyes and spectacles OTOH most often represent visibility.
Re: [whatwg] Placeholder option for text input boxes
"input.placeholder" is merely a notation; notation does not infer any semantics by itself. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith Sent: Tuesday, September 30, 2008 9:36 PM To: Nils Dagsson Moskopp Cc: whatwg Subject: Re: [whatwg] Placeholder option for text input boxes On Tue, Sep 30, 2008 at 12:14 PM, Nils Dagsson Moskopp <[EMAIL PROTECTED]> wrote: > Am Dienstag, den 30.09.2008, 11:49 -0700 schrieb Garrett Smith: >> Are there any arguments against a |placeholder| property on INPUT? > Missing semantics ? It is a purely presentational attribute. > The semantics would be simple property access: input.placeholder - as demonstrated in the example I posted up. Garrett
Re: [whatwg] Placeholder option for text input boxes
Please demonstrate a *valid* example of a placeholder containing a hint. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Lyttle Sent: Tuesday, September 30, 2008 9:29 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Placeholder option for text input boxes On Sep 30, 2008, at 12:14 PM, Nils Dagsson Moskopp wrote: > Am Dienstag, den 30.09.2008, 11:49 -0700 schrieb Garrett Smith: >> Are there any arguments against a |placeholder| property on INPUT? > Missing semantics ? It is a purely presentational attribute. It provides a hint to the user about what input is expected. It's no less semantic than title, which gets used for plenty of non-title- related things. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
I would rather test whether a brand new INPUT object of type SEARCH has an
attribute named "placeholder". Accessing attributes as properties is
discouraged and considered becoming obsolete; it should not be expected to
work for new attributes.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Tuesday, September 30, 2008 8:50 PM
To: [EMAIL PROTECTED]
Subject: [whatwg] Placeholder option for text input boxes
Result:
Safari 3.1 (supports placeholder)
zip.placeholder=undefined
zip.getAttributeNode('placeholder') =Zip Code
Others (do not support placeholder)
zip.placeholder=undefined
zip.getAttributeNode('placeholder') =Zip Code
If a backwards-compatible degradation strategy is to be devised, it
should be as trivial as checking:-
if(!('placeholder' in input)) {
createFallbackPlaceholder();
}
But this will fail in the current implementation in Safari 3.1.
input.getAttribute('placeholder') would not be degradable, as all
modern browsers would return the attribute value, regardless of
whether they support the actual placeholder behavior or not.
Are there any arguments against a |placeholder| property on INPUT?
Pros/cons for a |placeholder| property and attribute on TEXTAREA?
Garrett
> ~TJ
>
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sep 30, 2008, at 7:57 AM, Elliotte Harold wrote: Maciej Stachowiak wrote: More generally, I am on Apple's internal incoming security bug list, and I see Java applet security bugs all the time, so I think whatever the strength of the model may be, it does not lead to Java applets being secure in practice. Are those bugs in the model or in the VM? Stack overflow issues, buggy code, and such are of a different character than fundamental design flaws. Simple bugs can be fixed much more easily. Many of the bugs I see are about what applet has access to what network or local resources, i.e. failures of the access control model. I do not have direct knowledge of how easy these are to fix compared to other Java applet bugs. - Maciej
Re: [whatwg] Safari-compatible
On Sep 30, 2008, at 2:55 PM, Christoph Päper wrote: The magnifying glass was a particularly poor choice by Apple[1], because icons featuring one usually represent zooming (in). Binoculars are (for some reason) more common as symbols for searches. Eyes and spectacles OTOH most often represent visibility. Anyhow, the appearance of this or other types of |input| should not be specified by HTML5 / WF2+. Of course browsers could choose what the icon should look like; binoculars aren't a bad choice (although I think you're wrong about them being more common than a magnifying glass these days). The key is that the browser gives some sort of non-text indication to the user about the purpose of the field, in a platform-appropriate way. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
Tab Atkins Jr.: 1) @placeholder Con: Duplicates semantics already present in , (...) That could be circumvented by combining the two: Foo yielded [Foo ] whereas Foo resulted in [Bar ]. A similar observation as for |results|, concerning "binary" attributes, applies. Also I think the (textual) content of |label| is too hard to push into a placeholder text, because it may include all kinds of markup and style that it should or should not retain. 2) @alt Non-interactive UAs might choose to use |alt| instead of rendering form controls.
Re: [whatwg] Safari-compatible
Andy Lyttle: results - if present, shows a little magnifying glass icon, which helps to visually identify the field as a search box The magnifying glass was a particularly poor choice by Apple[1], because icons featuring one usually represent zooming (in). Binoculars are (for some reason) more common as symbols for searches. Eyes and spectacles OTOH most often represent visibility. Anyhow, the appearance of this or other types of |input| should not be specified by HTML5 / WF2+. results=10 - the magnifying glass functions as a drop-down menu containing a history of the last (whatever number) search terms I'm not sure, but I think it would be a first to have a "binary attribute" that is overloaded to alternatively also accept an integer as its value. Therefore would have to be equivalent to and not which looks wrong, because you would at least expect it to mean . [1] I could name a number of other poorly chosen Apple icons, but their fault usually is cultural bias or disharmony within a set.
Re: [whatwg] Safari-compatible
On Tue, 30 Sep 2008 12:40:23 +0100, Andy Lyttle <[EMAIL PROTECTED]> wrote: I would like Apple's adopted as an official standard, maintaining Safari compatibility. Comments? I like type=search. Special search box style is used throughout Mac OS X and Mac-centric sites try to fake it with borderless inputs that often end up looking broken. Windows has now a standard search box look too, so type=search would be good for intuitively looking search boxes across platforms. I'm in favor of placeholder on . It may be a bad UI, but it is used very often regardless. Standarizing it at least gives more control to UAs and frees authors from writing potentially buggy scripts (I haven't figured out yet how to write one that's not annoying on Opera Mini). I suggest ignoring onsearch and incremental attributes. They can be replaced with combination of oninput and onchange. I also don't like results and autosave. They're a bit confusing (if autosave=yes became popular, it would cause a mess). It can be abused (autosave=google's + script that puts site's own keywords just before user submits search). Such things are best controlled by browsers/users. To disable autosave authors could use autocomplete=off. -- regards, Kornel Lesinski
Re: [whatwg] Placeholder option for text input boxes
On Tue, Sep 30, 2008 at 12:14 PM, Nils Dagsson Moskopp <[EMAIL PROTECTED]> wrote: > Am Dienstag, den 30.09.2008, 11:49 -0700 schrieb Garrett Smith: >> Are there any arguments against a |placeholder| property on INPUT? > Missing semantics ? It is a purely presentational attribute. > The semantics would be simple property access: input.placeholder - as demonstrated in the example I posted up. Garrett > Cheers, > > Nils > >
Re: [whatwg] Placeholder option for text input boxes
On Sep 30, 2008, at 12:14 PM, Nils Dagsson Moskopp wrote: Am Dienstag, den 30.09.2008, 11:49 -0700 schrieb Garrett Smith: Are there any arguments against a |placeholder| property on INPUT? Missing semantics ? It is a purely presentational attribute. It provides a hint to the user about what input is expected. It's no less semantic than title, which gets used for plenty of non-title- related things. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
Am Dienstag, den 30.09.2008, 11:49 -0700 schrieb Garrett Smith: > Are there any arguments against a |placeholder| property on INPUT? Missing semantics ? It is a purely presentational attribute. Cheers, Nils
Re: [whatwg] Placeholder option for text input boxes
On Tue, Sep 30, 2008 at 1:46 PM, Andy Lyttle <[EMAIL PROTECTED]> wrote: > On Sep 30, 2008, at 10:54 AM, Tab Atkins Jr. wrote: > > Of course, the aesthetics of splitting the description between the > and the placeholder text can't always be denied. Semantically, though, > you're still using your s as headers in this situation, and then > providing the actual labels as placeholder text, and it would *still* be > best semantically to either mark it up explicitly as such (move > "Hair:"/"Nose:"/etc to a or and then ing the fields > with "Color:", "Shape", etc) or collapse the hierarchy and combine ( "Hair:" > becomes "Hair color:", etc.). > > > Legend is supposed to label a fieldset, not an individual field. > > > Facial Features > Eyes: > > Nose: > > > > Birth Information > Date of Birth: > > Place of Birth: > title="Enter the city and state where you were born"> > > Is this (the splitting of necessary descriptive information between label and placeholder text) sufficiently widespread enough to justify designing toward it? In every use of placeholder text *I've* seen in the wild, it was *only* used as a label *replacement*, not an augment. Frex, a forum I frequent has username and password fields shoved away very compactly into an infobar at the top of the screen, and uses placeholder text to indicate what they are for. You've provided cases where it *could* be useful, but in each of these it would be just as useful to the user to have that information in the label itself. It's really just the designer's aesthetic concerns that dictate it must be separated. Obviously this entire discussion is about mere aesthetics ultimately, but if a qualitatively better answer will solve 90% of use cases with greater ease, accessibility, and less coding, we should probably go with it. I'm arguing that a CSS-based packing of the text into the input is just such an answer.
Re: [whatwg] Placeholder option for text input boxes
Pros/cons for a |placeholder| property and attribute on TEXTAREA? As I understand it, it was sort of an accident that Safari supports placeholder on anything other than search fields, but there's no reason it shouldn't apply to all text input fields including textarea. I've just filed https://bugs.webkit.org/show_bug.cgi?id=21248 -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Safari-compatible
On Sep 30, 2008, at 10:23 AM, Kristof Zelechovski wrote: I am not against INPUT[type=search]; I am against INPUT[results=10] because I cannot see how it can be reasonably preset. Yeah, that's weird. I think if I designed it myself, I would have made the presence of autosave (instead of results) trigger the magnifying glass icon, used a sensible default for the number of items in the search history (maybe 10 or 20), used something like historylength to override it, and make setting historylength=0 disable the menu (leaving the icon). Something like that. But that's not how Apple did it, and we should be compatible with them. Is this control for simple search only or is it designed to be used in an advanced search interface? Should it be unique within a form? Excellent question! I imagine it should be unique within a form. Whether it's appropriate for an advanced search interface would depend on the interface; if there's one input that's an obvious choice for type="search" then go ahead and use it, otherwise it might be better to stick with type="text". Hopefully someone more qualified than I can provide a better answer. -- Andy Lyttle [EMAIL PROTECTED]
[whatwg] Placeholder option for text input boxes
-- Forwarded message --
From: Garrett Smith <[EMAIL PROTECTED]>
Date: Tue, Sep 30, 2008 at 11:49 AM
Subject: Re: [whatwg] Placeholder option for text input boxes
To: "Tab Atkins Jr." <[EMAIL PROTECTED]>
On Tue, Sep 30, 2008 at 10:04 AM, Tab Atkins Jr. <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle <[EMAIL PROTECTED]> wrote:
>>
>> On Sep 30, 2008, at 7:57 AM, Garrett Smith wrote:
>>>
>>> If and until user enters text, the "alternate" text is displayed.
>>>
>>> The confusing part is that successfully rendered inputs would be
>>> rendered and still use the alt.
>>>
>>> The good part is that it would be (or should be) accessible for screen
>>> readers.
>>
>> But alt here as you're describing it doesn't mean the same thing as alt
>> anywhere else. On an image, alt text says "this means the same thing as
>> what's supposed to be displayed." A placeholder does NOT mean the same
>> thing as whatever the user is going to enter.
>>
>> On the bright side, doing what you suggest shouldn't break anything
>> because I'm sure nobody's using it. However, I don't think that just
>> because we have an existing property defined that's used on other tags with
>> a different meaning, we should reuse that property for this meaning instead
>> of defining a new property.
>
> Agreed. Using @alt is a semantic hack.
>
> For the benefit of myself and others, I'm going to summarize the four
> current proposals.
>
> 1) @placeholder
> Pro: Already implemented in one major browser. Is opt-in, so doesn't
Partially implemented.
* 'placeholder' is not exposed as a DOM property.
* 'placeholder' is not implemented on TEXTAREA
For example, we can see a script which tries to get a 'placeholder'
property for an INPUT:
PlaceHolder
var d = document, input = d.forms[0].elements[0];
d.writeln(input.name + ".placeholder=" + input.placeholder);
d.writeln(input.name + ".getAttributeNode('placeholder') =" +
input.getAttribute('placeholder'));
Result:
Safari 3.1 (supports placeholder)
zip.placeholder=undefined
zip.getAttributeNode('placeholder') =Zip Code
Others (do not support placeholder)
zip.placeholder=undefined
zip.getAttributeNode('placeholder') =Zip Code
If a backwards-compatible degradation strategy is to be devised, it
should be as trivial as checking:-
if(!('placeholder' in input)) {
createFallbackPlaceholder();
}
But this will fail in the current implementation in Safari 3.1.
input.getAttribute('placeholder') would not be degradable, as all
modern browsers would return the attribute value, regardless of
whether they support the actual placeholder behavior or not.
Are there any arguments against a |placeholder| property on INPUT?
Pros/cons for a |placeholder| property and attribute on TEXTAREA?
Garrett
> ~TJ
>
Re: [whatwg] Placeholder option for text input boxes
On Sep 30, 2008, at 10:54 AM, Tab Atkins Jr. wrote: Eh, I'll still complain. ^_^ While all of your labels *would* be appropriate by themselves, the fact that you have to clarify them means they're not accurate enough for your purposes. Hey, I never said this was an example of good design - it's just an example of using labels for something that shouldn't be rendered as a placeholder, while also using placeholders. One must also consider the needs of people who are using browsers without the ability to render this placeholder text. They'll put "long" in hair, "two" in eyes, and "yes" in nose because they can't see the placeholder and are using their keyboard to navigate through your form (and thus won't see the tooltips either). Hopefully the site will designed well enough that the form is usable without the placeholder text or tooltips. For example, there could be instructions outside of the form that explain what is expected, with the placeholder serving as a subtle reminder to improve usability. As for accessibility, the goal is to mark it semantically so user agents have the opportunity to render it however is appropriate for their users, instead of the current JavaScript hacks that force a particular implementation. Safari is (AFAIK) the only user agent that currently implements placeholder; there's no reason to assume non-graphical user agents won't implement it in the same timeframe that other graphical user agents do. Of course, the aesthetics of splitting the description between the and the placeholder text can't always be denied. Semantically, though, you're still using your s as headers in this situation, and then providing the actual labels as placeholder text, and it would *still* be best semantically to either mark it up explicitly as such (move "Hair:"/"Nose:"/etc to a or and then ing the fields with "Color:", "Shape", etc) or collapse the hierarchy and combine ( "Hair:" becomes "Hair color:", etc.). Legend is supposed to label a fieldset, not an individual field. Facial Features Eyes: Nose: Birth Information Date of Birth: Place of Birth: Am I being anal and a little contrived about semantics to support my point? Of course, but that doesn't make my point invalid. ^_^ After all, what if you wanted hair length as well as color? You'd be forced to move to one of the two solutions - either promoting "Hair" to a full / in the and using "Color:" and "Length" as s or collapsing the label/placeholder dichotomy with "Hair color" and "Hair length" both as s or both as placeholders. Of course! If I wanted both hair color and hair length, it would be inappropriate to label both of them "Hair", and if I labeled them "Hair Color" and "Hair Length", then I wouldn't use "Color" as a placeholder (although I might use "Inches"). -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] workers
2008/9/30 Alexey Proskuryakov <[EMAIL PROTECTED]>: > Not really - it seems to me that they could work for shared workers as well, > but I need to think about it more. Creating/accessing a shared worker could > also create a default port that for use with Worker::postMessage, while all > messages from such would be forwarded to WorkerGlobalScope::onmessage > perhaps? Closing such a port wouldn't kill the worker thread, of course. I initially thought this too, but changed my mind. SharedWorkers are by definition meant to be used from multiple pages, so a developer will usually not use the default port since it would only work for the first client and not any other. If the developer only intended for their to be one client, he would just use DedicatedWorker. - a
Re: [whatwg] Placeholder option for text input boxes
Am Dienstag, den 30.09.2008, 12:04 -0500 schrieb Tab Atkins Jr.: > 4) (moving label textual content into as placeholder > text; currently with Javascript to mutate the DOM, in the future with > CSS to present the desired appearance while keeping the DOM stable) > Pro: Most semantic. Can be pushed site-wide without having to > change page code. Can't break existing content, because it is opt-in > (unless this gets put into browser default stylesheets). Accessible > (if using CSS solution; probably not accessible if DOM mutation is > employed). Degrades well (just stays an ordinary visible label if > browser doesn't support the rule). Wow. I'll now deny ever mentioning @title ! > Con: Most complex solution for implementors. Need to push proposal > through CSS WG, which can be slower than WHATWG. Since it's a purely presentational thing, that seems the way to go ! AFAIK, Development of CSS 3 will continue until 2011. Cheers, Nils
Re: [whatwg] Placeholder option for text input boxes
On Tue, Sep 30, 2008 at 12:37 PM, Andy Lyttle <[EMAIL PROTECTED]> wrote: > On Sep 30, 2008, at 7:00 AM, Tab Atkins Jr. wrote: > > Hm. I have a problem with your example. "Get local weather forecast" > isn't a semantic for the field - it doesn't describe what the field > is for. It describes what the *form* is for, and so should be a or > . "City, State" actually describes the use of the itself, and > should be the label. > > > Hmm, good call. Let's see if I can do better: > > Hair: > > > Eyes: > > > Nose: > > > Place of Birth: > title="Enter the city and state where you were born"> > > This shows how label AND placeholder AND title could be used for three > different purposes. If I were designing the spec from scratch, I might have > chosen "tooltip" and "hint" instead of "title" and "placeholder" > respectively, but we have to consider existing implementations. > Eh, I'll still complain. ^_^ While all of your labels *would* be appropriate by themselves, the fact that you have to clarify them means they're not accurate enough for your purposes. One must also consider the needs of people who are using browsers without the ability to render this placeholder text. They'll put "long" in hair, "two" in eyes, and "yes" in nose because they can't see the placeholder and are using their keyboard to navigate through your form (and thus won't see the tooltips either). Of course, the aesthetics of splitting the description between the and the placeholder text can't always be denied. Semantically, though, you're still using your s as headers in this situation, and then providing the actual labels as placeholder text, and it would *still* be best semantically to either mark it up explicitly as such (move "Hair:"/"Nose:"/etc to a or and then ing the fields with "Color:", "Shape", etc) or collapse the hierarchy and combine ( "Hair:" becomes "Hair color:", etc.). Am I being anal and a little contrived about semantics to support my point? Of course, but that doesn't make my point invalid. ^_^ After all, what if you wanted hair length as well as color? You'd be forced to move to one of the two solutions - either promoting "Hair" to a full / in the and using "Color:" and "Length" as s or collapsing the label/placeholder dichotomy with "Hair color" and "Hair length" both as s or both as placeholders. ~TJ
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, 30 Sep 2008, Edward Z. Yang wrote: In that case, you are certainly correct; adding a salt only hinders an attacker. But if we're worried about Origin giving away a secret intranet website, I think things should be reasonable. Of course, they can still dictionary brute-force it... I guess the concern is primarily over home users, as they seem to be particularly fond of referrer-blocking plugins and so forth - and if "Origin" becomes nearly as often blocked over rational or irrational fears, it would become much less useful. Corporations with large intranets probably care less, and there might be better ways to help them if they do (from RFC1918 checks on browser end, to proxies or internal redirectors that remove internal addresses only). /mz
[whatwg] Fwd: Placeholder option for text input boxes
blarg forward to list. -- Forwarded message -- From: Tab Atkins Jr. <[EMAIL PROTECTED]> Date: Tue, Sep 30, 2008 at 12:39 PM Subject: Re: [whatwg] Placeholder option for text input boxes To: Benjamin Hawkes-Lewis <[EMAIL PROTECTED]> On Tue, Sep 30, 2008 at 12:25 PM, Benjamin Hawkes-Lewis < [EMAIL PROTECTED]> wrote: > Tab Atkins Jr. wrote: > >> 2) @alt >> Pro: Presumably accessible to people with screen readers. >> > > Presumptions are risky. > > Is there any evidence (by which I mean a test case and a description of how > to reproduce behavior with real user agents) that demonstrates that this > would be true for INPUT TYPE="TEXT"? I can imagine screen readers resorting > to checking ALT to repair missing LABEL and TITLE; I'd be surprised if it > were common behavior otherwise. Likewise I can imagine users being able to > query for ALT, but this hardly seems like a natural interface for accessing > placeholder text. > I have no way of testing it, which is why it was merely "presumed". ^_^ I could certainly try to put together some test-cases, but I don't know what screen-readers are in common use (especially free ones). > 3) @title >> > > [snip] > > Not accessible. >> > > There are various accessibility problems @title in existing environments > and user agents: > > > http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-title-attributes/ > > However, implementations could be improved, just as support for > "placeholder" could be implemented. Ah, thanks for the link! From the information on that page, though, it looks as if the major problem with @title isn't an implementation issue, but rather an authoring issue. > 4) (moving label textual content into as placeholder text; >> currently with Javascript to mutate the DOM, in the future with CSS to >> present the desired appearance while keeping the DOM stable) >> Pro: Most semantic. >> > > Is it? How is it /more/ semantic than "placeholder", which would precisely > identify this text as a placeholder? Well, is "placeholder" a semantic category? To me, it seems much more like a presentational designation. The purpose it serves is to label the form input in a compact manner for space-limited layouts. In other words, it's a *label*, which we luckily already have an entire element and UI behavior built around. The fact that it sits *inside* the input rather than outside doesn't affect the semantics at all - it's still describing the purpose of the element for you. ~TJ
Re: [whatwg] Placeholder option for text input boxes
Benjamin Hawkes-Lewis wrote: Garrett Smith wrote: |placeholder| sounds a little like |alt|. Alt is a property and an attribute on INPUT. How is placeholder content for a form field alternative text? The alt text is for situations where the can not be displayed at all. For example an where the image fails to load or the user has disabled. Or you could imagine in theory if the UA supported turning off form controls entirely. The placeholder is content that is displayed along with a rendered form control. Thus placeholder is used along with the form control, alt is used instead of it. / Jonas
Re: [whatwg] Placeholder option for text input boxes
On Sep 30, 2008, at 7:00 AM, Tab Atkins Jr. wrote: Hm. I have a problem with your example. "Get local weather forecast" isn't a semantic for the field - it doesn't describe what the field is for. It describes what the *form* is for, and so should be a or . "City, State" actually describes the use of the itself, and should be the label. Hmm, good call. Let's see if I can do better: Hair: Eyes: Nose: Place of Birth: title="Enter the city and state where you were born"> This shows how label AND placeholder AND title could be used for three different purposes. If I were designing the spec from scratch, I might have chosen "tooltip" and "hint" instead of "title" and "placeholder" respectively, but we have to consider existing implementations. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Michal Zalewski wrote: > Not really? I just need to rebuild my dictionary for that salt, but to > check against say a million or ten million of common domains, it > wouldn't be very expensive. And it's not very expensive to build such a > list of domains, too. In that case, you are certainly correct; adding a salt only hinders an attacker. But if we're worried about Origin giving away a secret intranet website, I think things should be reasonable. Of course, they can still dictionary brute-force it... (whoops, forgot to CC list)
Re: [whatwg] workers
Sep 30, 2008, в 9:11 PM, Aaron Boodman написал(а): Do you have any thoughts on the extra API on dedicated workers proposed by Jonas (DedicatedWorker::sendMessage, DedicatedWorkerGlobalScope::onmessage)? Not really - it seems to me that they could work for shared workers as well, but I need to think about it more. Creating/accessing a shared worker could also create a default port that for use with Worker::postMessage, while all messages from such would be forwarded to WorkerGlobalScope::onmessage perhaps? Closing such a port wouldn't kill the worker thread, of course. - WBR, Alexey Proskuryakov
Re: [whatwg] Placeholder option for text input boxes
Tab Atkins Jr. wrote: 2) @alt Pro: Presumably accessible to people with screen readers. Presumptions are risky. Is there any evidence (by which I mean a test case and a description of how to reproduce behavior with real user agents) that demonstrates that this would be true for INPUT TYPE="TEXT"? I can imagine screen readers resorting to checking ALT to repair missing LABEL and TITLE; I'd be surprised if it were common behavior otherwise. Likewise I can imagine users being able to query for ALT, but this hardly seems like a natural interface for accessing placeholder text. 3) @title [snip] Not accessible. There are various accessibility problems @title in existing environments and user agents: http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-title-attributes/ However, implementations could be improved, just as support for "placeholder" could be implemented. 4) (moving label textual content into as placeholder text; currently with Javascript to mutate the DOM, in the future with CSS to present the desired appearance while keeping the DOM stable) Pro: Most semantic. Is it? How is it /more/ semantic than "placeholder", which would precisely identify this text as a placeholder? -- Benjamin Hawkes-Lewis
Re: [whatwg] Safari-compatible
I am not against INPUT[type=search]; I am against INPUT[results=10] because I cannot see how it can be reasonably preset. Is this control for simple search only or is it designed to be used in an advanced search interface? Should it be unique within a form? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Lyttle Sent: Tuesday, September 30, 2008 7:03 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Safari-compatible On Sep 30, 2008, at 7:18 AM, Kristof Zelechovski wrote: > How can the Web designer know how many recent search terms the user > would > like to keep handy at the search box? The same way the web designer knows anything else: taking an educated guess at what would be most appropriate for their users. Personally, I would have done it a little differently and called this property something other than "results", but Apple has already done it, and there is value in staying compatible with them. > What if autosave strings clash, or get deliberately stepped upon? You can avoid clashing by using reverse-FQDN notation, e.g. autosave="com.phroggy.weblog.search", or using your company name or other trademark. It is OK for them to be deliberately stepped upon - this is actually a design feature. If you want to make a search field on your site that searches my site (submitting to the same CGI that my form submits to), you can specify the same autosave string that I use, and search history will be shared between both forms. There is no security problem, because the search history list is not accessible to you (or me) unless the user explicitly chooses an item from it (which you can't distinguish from pasting in a string from elsewhere). > I think it is a user preference + browser QoI and Web sites should > not try > to outsmart it. The whole point of this is to provide sensible markup that the browser can use to figure out the best way to handle it. Browsers aren't obligated to handle search history at all if the user doesn't want them to. Using gives users MORE choice about how the browser should behave, by providing more information about what the web designer was trying to do, instead of using CSS and JavaScript hacks to implement a specific behavior that may not be desirable to some users. > Marking a box as a search box is already there (ISINDEX, > deprecated). Nobody uses that, and it's not a form element. We could resurrect it, but I don't see a compelling reason to do so. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, 30 Sep 2008, Edward Z. Yang wrote: More importantly, since the dictionary of possible inputs is rather limited, it would be pretty trivial to build a dictionary of site <-> hash pairs and crack the values. May protect xyzzy2984.eur.int.example.com, but would still reveal to me you are coming from playboy.com. Salt it. Problem solved. Not really? I just need to rebuild my dictionary for that salt, but to check against say a million or ten million of common domains, it wouldn't be very expensive. And it's not very expensive to build such a list of domains, too. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Michal Zalewski wrote: > More importantly, since the dictionary of possible inputs is rather > limited, it would be pretty trivial to build a dictionary of site <-> > hash pairs and crack the values. May protect > xyzzy2984.eur.int.example.com, but would still reveal to me you are > coming from playboy.com. Salt it. Problem solved.
Re: [whatwg] Safari-compatible
On Sep 30, 2008, at 7:40 AM, Nils Dagsson Moskopp wrote: I assume that this should be based on the search elements ID attribute, am I right ? Because common UA behaviour already is to cache entries (based on ID) ... so what unsolved problem is solved there ? If I have a form on my site, using a particular autosave string for a search field, you can create a form on your site that submits to the same CGI URL, with a search field that uses the same autosave string, and browsers will know that they should share the search history between both forms. This is not a security problem, because the history list is not accessible to you (or me). I don't see this feature getting a lot of use, but Apple has already implemented it, and I don't see a compelling reason not to support it. And who knows, if it's supported, maybe someone will think of some clever use for it that I haven't thought of, that couldn't have been done well without this feature. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] workers
2008/9/30 Alexey Proskuryakov <[EMAIL PROTECTED]>: > Hmm... So this is more about how you use the interface, not what the object > behind it is. If one chooses to never call close() on a shared worker (or, > say, sets myWorker.close to null right after invoking constructor), it > becomes indistinguishable from a dedicated worker. > > Hiding close() possibly sounds more like something a high-level framework > may want to do to enforce a certain design pattern than a core feature. I could see that too. When all the parties accessing a shared worker are from the same origin (as they are today) it is less of an issue. You can probably assume that they know not to close() the worker. Do you have any thoughts on the extra API on dedicated workers proposed by Jonas (DedicatedWorker::sendMessage, DedicatedWorkerGlobalScope::onmessage)? - a
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, 30 Sep 2008, Adam Barth wrote: This could be addressed by sending a cryptographic hash of the origin (using an algorithm that is commonly available in libraries used by server-side programmers). Interesting idea. So you're suggesting something like: Origin-SHA1: 4e13de73de2d1a1c350eb4ae429bb7b009a21a84 This sounds like it would work well if the site owner knew exactly all the origins he was expecting, but it makes it difficult to enforce a policy like "process this request if it came from a subdomain of example.com." More importantly, since the dictionary of possible inputs is rather limited, it would be pretty trivial to build a dictionary of site <-> hash pairs and crack the values. May protect xyzzy2984.eur.int.example.com, but would still reveal to me you are coming from playboy.com. /mz
Re: [whatwg] Placeholder option for text input boxes
On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle <[EMAIL PROTECTED]> wrote: > On Sep 30, 2008, at 7:57 AM, Garrett Smith wrote: > >> If and until user enters text, the "alternate" text is displayed. >> >> The confusing part is that successfully rendered inputs would be >> rendered and still use the alt. >> >> The good part is that it would be (or should be) accessible for screen >> readers. >> > > But alt here as you're describing it doesn't mean the same thing as alt > anywhere else. On an image, alt text says "this means the same thing as > what's supposed to be displayed." A placeholder does NOT mean the same > thing as whatever the user is going to enter. > > On the bright side, doing what you suggest shouldn't break anything because > I'm sure nobody's using it. However, I don't think that just because we > have an existing property defined that's used on other tags with a different > meaning, we should reuse that property for this meaning instead of defining > a new property. Agreed. Using @alt is a semantic hack. For the benefit of myself and others, I'm going to summarize the four current proposals. 1) @placeholder Pro: Already implemented in one major browser. Is opt-in, so doesn't interfere with existing content at all. Degrades acceptably. Con: Duplicates semantics already present in , @alt, and @title to some extent. Is essentially a presentational attribute. Not (currently) accessible. Won't be widely usable until all browsers support it (ie, degrades silently rather than usefully). 2) @alt Pro: Presumably accessible to people with screen readers. Probably not currently in use at all, so new function won't disrupt existing content. Con: Semantic hack - it's not "alternative content", it's *normal* content, just used to introduce the element. May collide with future uses of @alt if a UI allows form elements to not be displayed (however, no idea how/why this would work) 3) @title Pro: Reasonably semantic. Relatively similar in current usage. Degrades acceptably. Con: Good reasons to allow both placeholder text *and* tooltips. Can break existing content that either expects @title info in a tooltip, or that has @title that is too long to be placed easily in the . Not accessible. 4) (moving label textual content into as placeholder text; currently with Javascript to mutate the DOM, in the future with CSS to present the desired appearance while keeping the DOM stable) Pro: Most semantic. Can be pushed site-wide without having to change page code. Can't break existing content, because it is opt-in (unless this gets put into browser default stylesheets). Accessible (if using CSS solution; probably not accessible if DOM mutation is employed). Degrades well (just stays an ordinary visible label if browser doesn't support the rule). Con: Most complex solution for implementors. Need to push proposal through CSS WG, which can be slower than WHATWG. ~TJ
Re: [whatwg] Safari-compatible
On Sep 30, 2008, at 7:18 AM, Kristof Zelechovski wrote: How can the Web designer know how many recent search terms the user would like to keep handy at the search box? The same way the web designer knows anything else: taking an educated guess at what would be most appropriate for their users. Personally, I would have done it a little differently and called this property something other than "results", but Apple has already done it, and there is value in staying compatible with them. What if autosave strings clash, or get deliberately stepped upon? You can avoid clashing by using reverse-FQDN notation, e.g. autosave="com.phroggy.weblog.search", or using your company name or other trademark. It is OK for them to be deliberately stepped upon - this is actually a design feature. If you want to make a search field on your site that searches my site (submitting to the same CGI that my form submits to), you can specify the same autosave string that I use, and search history will be shared between both forms. There is no security problem, because the search history list is not accessible to you (or me) unless the user explicitly chooses an item from it (which you can't distinguish from pasting in a string from elsewhere). I think it is a user preference + browser QoI and Web sites should not try to outsmart it. The whole point of this is to provide sensible markup that the browser can use to figure out the best way to handle it. Browsers aren't obligated to handle search history at all if the user doesn't want them to. Using gives users MORE choice about how the browser should behave, by providing more information about what the web designer was trying to do, instead of using CSS and JavaScript hacks to implement a specific behavior that may not be desirable to some users. Marking a box as a search box is already there (ISINDEX, deprecated). Nobody uses that, and it's not a form element. We could resurrect it, but I don't see a compelling reason to do so. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] workers
Sep 30, 2008, в 8:46 PM, Aaron Boodman написал(а): close() was added so that you could forcibly kill a worker. For example, if you are searching a large set with many workers, you may want to kill them once one finds a match. ... So I think it is useful to have a conceptual difference between workers that are 'dedicated' and those that are 'shared'. Hmm... So this is more about how you use the interface, not what the object behind it is. If one chooses to never call close() on a shared worker (or, say, sets myWorker.close to null right after invoking constructor), it becomes indistinguishable from a dedicated worker. Hiding close() possibly sounds more like something a high-level framework may want to do to enforce a certain design pattern than a core feature. - WBR, Alexey Proskuryakov
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, Sep 30, 2008 at 9:31 AM, Henri Sivonen <[EMAIL PROTECTED]> wrote: > This could be addressed by sending a cryptographic hash of the origin (using > an algorithm that is commonly available in libraries used by server-side > programmers). Interesting idea. So you're suggesting something like: Origin-SHA1: 4e13de73de2d1a1c350eb4ae429bb7b009a21a84 This sounds like it would work well if the site owner knew exactly all the origins he was expecting, but it makes it difficult to enforce a policy like "process this request if it came from a subdomain of example.com." Also, as a server operator, if I start getting a bunch of requests with a new origin hash, I'd have to guess whether this was an attack or another service on my network that I forgot about. (Traffic volumes might be a good clue about this.) Adam
Re: [whatwg] workers
2008/9/30 Alexey Proskuryakov <[EMAIL PROTECTED]>: > I'm not sure it's so good in the case of dedicated workers either, as they > can be used from other contexts via additional message ports. The close() > method could just close the default port. Sure, but in order for that to have happened, whoever created the worker in the first place must have done it on purpose. The original worker instance is anonymous. If the creator of that worker decides to share it, that's fine, but it's more like cooperative sharing. close() was added so that you could forcibly kill a worker. For example, if you are searching a large set with many workers, you may want to kill them once one finds a match. The same could be achieved by just setting all the ports to null and waiting for GC, but: a) GC might not be for awhile, which is wasteful b) It is hard to track where all the ports went So I think it is useful to have a conceptual difference between workers that are 'dedicated' and those that are 'shared'. - a
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Elliotte Harold writes: > Large content providers already move their content closer to the end > user. They do this by physically locating boxes with the same host > name and fancy DNS and router tricks. Yup. But those are _large_ content providers. We shouldn't design HTML 5 such that smaller players are at a disadvantage (because they aren't big enough to warrant doing such things themselves, and they can't outsource things to a third party because we've blocked such services from working). Smylers
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Elliotte Harold writes: > Smylers wrote: > > > > That's a sometimes convenient feature for site developers, but > > > there's nothing you can do with content loaded from two sites you > > > can't do with content loaded from one. > > > > Here's some I can think of: > > > > * Many sites are funded by displaying adverts from a third-party > > service which picks appropriate ads for the current user-page > > combination. > > Serve ads from the host site. That's fine if the host site can do it. But often the point of subcontracting something to a third party is through lack of ability to do it oneself. A website on a particular topic may be financially viable by running third-party-provided ads; that requires merely a standard template in each page, a one-off cost which can be forgotten about. Whereas running ads themselves would take ongoing effort by the site (uploading them, making the pages link to them). That may reduce the time those running the site have available to work on the site's content. Or they may have to pay somebody else to set up the ads. Either of which could make the site no longer financially viable. > > Further, I don't see how users can be tracked across multiple sites. > > This is useful to serve users a variety of different ads, rather than > > the same one lots of times, even as they read multiple sites which all > > use the same third party ad service. > > That's a feature, not a bug. Or another way: users shouldn't be able > to be tracked across sites. That they are is a bug, not a feature. If I'm going to see ads, I'd rather get different ads than repeatedly encounter the same ones. > > * Third party traffic analysis services, ranging from simple image > > hit-counters to something like Google Analytics, require being > > part of a page's loading. > > Not all such services do require this though. That's true. > I don't have time to respond in detail to each of the valid points > your raise. I may later. No, I understand your general point, and I'm sure for each of them I could come up with an alternative technical implementation. It's just that I think such alternatives require sites to make other changes -- changes to their business models, such as switching to a more advanced hosting package, or having to perform in-house tasks which were previously outsourced. And of course they break the business models of some of the outsources, whose products could no longer be used. > If we break these things such that third party content is no longer > the simplest solution that could possibly work, then developers and > sites will move on to the next simplest solution. Or they won't bother, and sites that currently exist will give up. > Addressing the root cause will cause pain because a lot of systems you > mention will have to be rewritten to work in the new world. Indeed; that's my major concern here. HTML in general is a sub-optimal. XHTML 2 tried the approach of accepting transition pain in order to move to a saner place, but that doesn't seem to have gained traction. I'm simply not persuaded that those who would have to pay the cost of that pain will accept it. The first time a browser is released that implements this idea, many existing sites will fail. Users will blame the browser (we know that because Mozilla-based browsers got blamed for things it did correctly but differently from IE, such as alt text not being in a tooltip). At that point, all other browsers (and older releases of that browser) will still work. Why would users bother switching? And if users don't switch, why would sites bother updating themselves? Nor do I see that it is within the remit of HTML 5 to outlaw certain business models that were permitted under HTML 4. We're saying that such sites aren't welcome on the web? What if such sites are served with valid HTML 4; should they still have HTML 5's new rules applied to them? > So be it. For any suggestion on this mailing list it's proponents could dismiss its costs with "so be it". That doesn't in any way justify why those costs are worthwhile. You appear to be arguing here that the costs are worth it no matter how high they are. Simon
Re: [whatwg] Placeholder option for text input boxes
On Sep 30, 2008, at 7:57 AM, Garrett Smith wrote: If and until user enters text, the "alternate" text is displayed. The confusing part is that successfully rendered inputs would be rendered and still use the alt. The good part is that it would be (or should be) accessible for screen readers. But alt here as you're describing it doesn't mean the same thing as alt anywhere else. On an image, alt text says "this means the same thing as what's supposed to be displayed." A placeholder does NOT mean the same thing as whatever the user is going to enter. On the bright side, doing what you suggest shouldn't break anything because I'm sure nobody's using it. However, I don't think that just because we have an existing property defined that's used on other tags with a different meaning, we should reuse that property for this meaning instead of defining a new property. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sep 29, 2008, at 23:52, Adam Barth wrote: On Mon, Sep 29, 2008 at 1:40 PM, Anne van Kesteren <[EMAIL PROTECTED]> wrote: I thought the issue with Referer was that it exposed path information, but I guess the problem with Origin is that it reveals the intranet server name? The query string and the path are probably the most privacy-sensitive. Yes, the concern is revealing the name of an intranet server. Most names are probably innocuous (like www, hr, or wiki), but there are others that might be an issue (like secretproject). It's hard for me to evaluate how concerning this privacy leak is. This could be addressed by sending a cryptographic hash of the origin (using an algorithm that is commonly available in libraries used by server-side programmers). -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Placeholder option for text input boxes
On Sep 30, 2008, at 8:33 AM, Nils Dagsson Moskopp wrote: No, I meant to abolish the placeholder attribute alltogether and render the title attribute as greyed-sut inside the search box instead, because * semantically, the title attribute conveys the same information. * it is already there in many pages. Except that: 1) the title attribute doesn't behave this way on any other element 2) there's no reason it shouldn't be possible to have both a placeholder AND a tooltip 3) anybody who is currently using the title attribute doesn't expect it to be displayed as a placeholder, so we would break things for them (especially if their title string is too long to fit inside a small field) -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] workers
Sep 30, 2008, в 7:19 PM, Aaron Boodman написал(а): I'm of the opinion that there should be as little difference as possible, to lower the amount of API to learn. Therefore in my preferred proposal, the only difference between SharedWorker and DedicatedWorker is that the latter has a close() method. It doesn't make sense to allow one user of a SharedWorker to close something others are depending on. I'm not sure it's so good in the case of dedicated workers either, as they can be used from other contexts via additional message ports. The close() method could just close the default port. Both shared and dedicated workers have to maintain a strong reference to a context that created them, just to have a context to execute event listeners in. So, they are basically the same as far as implementation is concerned AFAICT. - WBR, Alexey Proskuryakov
Re: [whatwg] Placeholder option for text input boxes
Am Dienstag, den 30.09.2008, 08:25 -0700 schrieb Garrett Smith: > (Nils, did you mean to put this on the list, or is this personal mail?) I meant to put it on the list - didn't it go there ? > >> If and until user enters text, the "alternate" text is displayed. > >> > >> The confusing part is that successfully rendered inputs would be > >> rendered and still use the alt. > >> > >> The good part is that it would be (or should be) accessible for screen > >> readers. > > why not just use the title attribute for that ? > > > > Like this: > > > ? > > So when you mouse over the input, the yellow tooltip would pop up. > > That's annoying. No, I meant to abolish the placeholder attribute alltogether and render the title attribute as greyed-sut inside the search box instead, because * semantically, the title attribute conveys the same information. * it is already there in many pages. Cheers, Nils
Re: [whatwg] workers
2008/9/30 Alexey Proskuryakov <[EMAIL PROTECTED]>:
> Sep 24, 2008, в 10:38 PM, Aaron Boodman написал(а):
>
>> interface DedicatedWorker : Worker {
>
> I've been trying to understand the difference between SharedWorker and
> DedicatedWorker interfaces. Besides the ability to pick an existing worker
> by name, are there any other semantic differences? I may be missing
> something, but it looks like a single Worker interface with an optional name
> parameter to constructor would work just as well.
That is what we are debating here. Logically, there is a concept of a
"shared worker", which can be referenced from multiple pages in the
same origin. There is a debate about how much the interface between
shared workers and dedicated workers should be different.
I'm of the opinion that there should be as little difference as
possible, to lower the amount of API to learn. Therefore in my
preferred proposal, the only difference between SharedWorker and
DedicatedWorker is that the latter has a close() method. It doesn't
make sense to allow one user of a SharedWorker to close something
others are depending on.
Jonas is in favor of making a particular use case of DedicatedWorker
as simple to use as possible. This requires extra API on
DedicatedWorker that doesn't make sense for SharedWorker.
>> void sendMessage(String message);
>
> The WHATWG draft calls this postMessage() - is this just a different name,
> or an implied substantial difference in behavior?
No that was a mistake on my part. It should be called postMessage.
- a
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
I am afraid we are going in circles here. You suggested that the embedded content should be stored on the server that provides the interface. Now you explain how it can be stored on the media provider's server. That is nothing new - except that it has nothing to do with your original position. Chris -Original Message- From: Elliotte Harold [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 5:03 PM To: Kristof Zelechovski Cc: 'WHAT WG List' Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web Kristof Zelechovski wrote: > If you set up a mirror with the same host name as the content provider has, > you will probably get sued for identity theft, cybersquatting, forgery or > whatever. > No, only the content provider (really the domain name owner) can set up these mirrors. This is nothing new. This is how the web and DNS work *today*. Many high volume sites such as www.google.com, www.amazon.com, www.nytimes.com, and so forth--send you to different physical boxes depending on where you're connecting from. These boxes are usually chosen to be close to the end user. For instance, a reader on the east Coast might get www.nytimes.com in New York but one on the West Coast might get a box in Los Angeles. A reader in Japan might get a box in Japan. (I don't know if this is actually how the NYT seets up its servers or not. Some tracerouting from different locations might find out quickly.) Large content providers already move their content closer to the end user. They do this by physically locating boxes with the same host name and fancy DNS and router tricks. The details are complex, which is why CCNAs get the big bucks. But they do not do this by linking to 3rd party content. -- Elliotte Rusty Harold [EMAIL PROTECTED] Refactoring HTML Just Published! http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Kristof Zelechovski wrote: If you set up a mirror with the same host name as the content provider has, you will probably get sued for identity theft, cybersquatting, forgery or whatever. No, only the content provider (really the domain name owner) can set up these mirrors. This is nothing new. This is how the web and DNS work *today*. Many high volume sites such as www.google.com, www.amazon.com, www.nytimes.com, and so forth--send you to different physical boxes depending on where you're connecting from. These boxes are usually chosen to be close to the end user. For instance, a reader on the east Coast might get www.nytimes.com in New York but one on the West Coast might get a box in Los Angeles. A reader in Japan might get a box in Japan. (I don't know if this is actually how the NYT seets up its servers or not. Some tracerouting from different locations might find out quickly.) Large content providers already move their content closer to the end user. They do this by physically locating boxes with the same host name and fancy DNS and router tricks. The details are complex, which is why CCNAs get the big bucks. But they do not do this by linking to 3rd party content. -- Elliotte Rusty Harold [EMAIL PROTECTED] Refactoring HTML Just Published! http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA
Re: [whatwg] Placeholder option for text input boxes
On Tue, Sep 30, 2008 at 12:37 AM, Benjamin Hawkes-Lewis <[EMAIL PROTECTED]> wrote: > Garrett Smith wrote: >> >> |placeholder| sounds a little like |alt|. Alt is a property and an >> attribute on INPUT. > > How is placeholder content for a form field alternative text? > If and until user enters text, the "alternate" text is displayed. The confusing part is that successfully rendered inputs would be rendered and still use the alt. The good part is that it would be (or should be) accessible for screen readers. > -- > Benjamin Hawkes-Lewis >
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Maciej Stachowiak wrote: More generally, I am on Apple's internal incoming security bug list, and I see Java applet security bugs all the time, so I think whatever the strength of the model may be, it does not lead to Java applets being secure in practice. Are those bugs in the model or in the VM? Stack overflow issues, buggy code, and such are of a different character than fundamental design flaws. Simple bugs can be fixed much more easily. -- Elliotte Rusty Harold [EMAIL PROTECTED] Refactoring HTML Just Published! http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Smylers wrote: That's a sometimes convenient feature for site developers, but there's nothing you can do with content loaded from two sites you can't do with content loaded from one. Here's some I can think of: * Many sites are funded by displaying adverts from a third-party service which picks appropriate ads for the current user-page combination. Serve ads from the host site. Further, I don't see how users can be tracked across multiple sites. This is useful to serve users a variety of different ads, rather than the same one lots of times, even as they read multiple sites which all use the same third party ad service. That's a feature, not a bug. Or another way: users shouldn't be able to be tracked across sites. That they are is a bug, not a feature. * Third party traffic analysis services, ranging from simple image hit- counters to something like Google Analytics, require being part of a page's loading. Not all such services do require this though. Google Analytics implementation decisions are not the only ones possible. I don't have time to respond in detail to each of the valid points your raise. I may later. However each of them can be handled in a different way that doesn't require third party content and mashups. The reason we have designed these systems this way is because it was quick and easy, not because it was the only way to do these tasks. If we break these things such that third party content is no longer the simplest solution that could possibly work, then developers and sites will move on to the next simplest solution. The bottom line is that bad implementation decisions made years ago with respect to third party content are causing security issues now. We can't paper over these problems. Anything less than addressing the root cause will fail. Addressing the root cause will cause pain because a lot of systems you mention will have to be rewritten to work in the new world. So be it. Nothing else will work, and the sooner we recognize that, the sooner everything will be fixed. -- Elliotte Rusty Harold [EMAIL PROTECTED] Refactoring HTML Just Published! http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA
Re: [whatwg] Safari-compatible
Am Dienstag, den 30.09.2008, 15:31 +0100 schrieb João Eiras: > > How can the Web designer know how many recent search terms the user would > > like to keep handy at the search box? > > He/she can't know, and providing that info would be a privacy issue. > input with type search would simply tell the UA to keep entries typed > in memory for later reuse, which is a bonus for usability, I assume that this should be based on the search elements ID attribute, am I right ? Because common UA behaviour already is to cache entries (based on ID) ... so what unsolved problem is solved there ?
Re: [whatwg] Safari-compatible
> How can the Web designer know how many recent search terms the user would > like to keep handy at the search box? He/she can't know, and providing that info would be a privacy issue. input with type search would simply tell the UA to keep entries typed in memory for later reuse, which is a bonus for usability, and spared the page uathro of javascript kungfudeathgrips and bloated js libraries to provide trivial functionality. On Tue, Sep 30, 2008 at 3:18 PM, Kristof Zelechovski <[EMAIL PROTECTED]> wrote: > How can the Web designer know how many recent search terms the user would > like to keep handy at the search box? > What if autosave strings clash, or get deliberately stepped upon? > I think it is a user preference + browser QoI and Web sites should not try > to outsmart it. Marking a box as a search box is already there (ISINDEX, > deprecated). > Chris > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Andy Lyttle > Sent: Tuesday, September 30, 2008 1:40 PM > To: whatwg@lists.whatwg.org > Subject: [whatwg] Safari-compatible > > I would like Apple's adopted as an official > standard, maintaining Safari compatibility. Attributes are: > > onsearch="foo();" - JavaScript function called when the user > initiates a search > > incremental - if present, onsearch fires on every keypress, and on > clicking the cancel button; otherwise onsearch fires when pressing Enter > > results - if present, shows a little magnifying glass icon, which > helps to visually identify the field as a search box > > results=10 - the magnifying glass functions as a drop-down menu > containing a history of the last (whatever number) search terms > > autosave="foo" - define a unique name to identify the search history > (so the same history may be shared across multiple search boxes, even > across different domains) > > > >
Re: [whatwg] Safari-compatible
How can the Web designer know how many recent search terms the user would like to keep handy at the search box? What if autosave strings clash, or get deliberately stepped upon? I think it is a user preference + browser QoI and Web sites should not try to outsmart it. Marking a box as a search box is already there (ISINDEX, deprecated). Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Lyttle Sent: Tuesday, September 30, 2008 1:40 PM To: whatwg@lists.whatwg.org Subject: [whatwg] Safari-compatible I would like Apple's adopted as an official standard, maintaining Safari compatibility. Attributes are: onsearch="foo();" - JavaScript function called when the user initiates a search incremental - if present, onsearch fires on every keypress, and on clicking the cancel button; otherwise onsearch fires when pressing Enter results - if present, shows a little magnifying glass icon, which helps to visually identify the field as a search box results=10 - the magnifying glass functions as a drop-down menu containing a history of the last (whatever number) search terms autosave="foo" - define a unique name to identify the search history (so the same history may be shared across multiple search boxes, even across different domains)
Re: [whatwg] Placeholder option for text input boxes
On Tue, Sep 30, 2008 at 4:10 AM, Andy Lyttle <[EMAIL PROTECTED]> wrote: > I do not like this idea at all. That is what LABEL is for, and >> disappearing >> "it's so kewl" text is as annoying as BLINK and BGSOUND. >> Chris >> > > The tag is great for labels that are displayed outside the input > box (in front of, above, etc.). The placeholder attribute is intended more > as a hint than a label, and is displayed inside the input box without taking > up any additional space on the page. An example might be: > > Get local weather forecast: > > > Using the "alt" attribute has been suggested here, but no implementation > uses "alt" in this way, while "placeholder" is already supported by one > major browser (and since it really isn't alternate text, using "alt" doesn't > make any sense). Another suggestion was to use the "title" attribute, which > is a better idea, but "title" is generally implemented as a tooltip that > doesn't appear until you hover over the element, which is not the desired > behavior. It's perfectly legitimate to use a tag AND title AND > placeholder attributes, for three subtly different purposes. Hm. I have a problem with your example. "Get local weather forecast" isn't a semantic for the field - it doesn't describe what the field is for. It describes what the *form* is for, and so should be a or . "City, State" actually describes the use of the itself, and should be the label. I'd suspect that *all* examples where placeholder text is used (definitely all the examples I know of personally) are most semantically served by a with the text. Iirc, I once saw a nice javascript solution that mutated the DOM to remove the and use its text as a placeholder. Thus, I think this is best served by a CSS directive that does exactly that. External vs placeholder text is a display issue - semantically, both are labels for the field. The only question would be whether to make this a property of or ... Probably - targetting would result in action-at-a-distance. ~TJ
Re: [whatwg] workers
Sep 24, 2008, в 10:38 PM, Aaron Boodman написал(а):
interface DedicatedWorker : Worker {
I've been trying to understand the difference between SharedWorker and
DedicatedWorker interfaces. Besides the ability to pick an existing
worker by name, are there any other semantic differences? I may be
missing something, but it looks like a single Worker interface with an
optional name parameter to constructor would work just as well.
void sendMessage(String message);
The WHATWG draft calls this postMessage() - is this just a different
name, or an implied substantial difference in behavior?
- WBR, Alexey Proskuryakov
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Wed, 1 Oct 2008, Robert O'Callahan wrote: I don't think that's secure. The outer page can set the IFRAME's URL to contain a #xyz fragment identifier That's really covered in the original proposal. Honest :P In a kludgy manner, of course (permitting fragments, but not permitting onload scrolling based on fragments in cross-domain settings), but we thought of this one. /mz
[whatwg] Safari-compatible
I would like Apple's adopted as an official standard, maintaining Safari compatibility. Attributes are: onsearch="foo();" - JavaScript function called when the user initiates a search incremental - if present, onsearch fires on every keypress, and on clicking the cancel button; otherwise onsearch fires when pressing Enter results - if present, shows a little magnifying glass icon, which helps to visually identify the field as a search box results=10 - the magnifying glass functions as a drop-down menu containing a history of the last (whatever number) search terms autosave="foo" - define a unique name to identify the search history (so the same history may be shared across multiple search boxes, even across different domains) All other attributes of are also supported, including placeholder. Apple's implementation adds a cancel (x) button which appears whenever text has been typed into the box; clicking the cancel button clears the text without removing focus. They also use rounded corners to make search boxes visually distinct from plain text boxes. Web sites are already implementing some of this functionality through JavaScript, CSS and graphics. Examples of Apple's visual appearance (rounded corners and magnifying glass): http://www.apple.com/ http://www.filemaker.com/ http://www.britannica.com/ (but doesn't hide the cancel button when value="") Other examples of search fields with a variety of non-square corners: http://www.cnet.com/ http://www.myspace.com/ http://wordpress.com/ http://www.target.com/ http://www.lenovo.com/us/en/index.html Examples of incremental search functionality using AJAX: http://www.apple.com/ http://www.adobe.com/ At first glance it looks like onsearch (when combined with incremental) is identical to oninput, but onsearch fires after a slight delay, so that if the user rapidly types multiple characters, the search doesn't begin until after a sufficient pause in typing. For AJAX queries (or CPU-intensive client-side processing), this behavior is much better than using oninput, which fires for every single keystroke. Of course the behavior of onsearch could be emulated through JavaScript, but having onsearch eliminates the need to reinvent that wheel. I really like having a little magnifying glass icon that I don't have to draw myself (or steal from somewhere) and then use crazy CSS tricks to get it to look like it's inside the search box. The implementation can be platform-specific of course; for example on Windows the magnifying glass might look like this: http://justaddwater.dk/wp-content/uploads/2006/01/vista%20search.jpg and that could be replaced by a cancel button when you start typing: http://www.tech2.com/media/images/img_3781_vista_search.jpg Safari has supported these features for some time, and we should not break compatibility with them: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011368.html Google has said they'd like to be compatible with Safari: http://code.google.com/p/chromium/issues/detail?id=17#c9 The main thing is, if these features were standardized, more sites would use them instead of trying to come up with something clever on their own, which would lead to more consistency across sites and a better user experience. Comments? -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, Sep 30, 2008 at 10:33 PM, Michal Zalewski <[EMAIL PROTECTED]> wrote: > On Tue, 30 Sep 2008, Robert O'Callahan wrote: > > If I understand correctly, with Michal's option 3, those sites would also >> stop working as soon as the user scrolled down in the framed page (so that >> the top-left of the framed page is out of view). >> > > Nope, the restriction applies strictly to the top-left corner of the > *container* getting scrolled of the screen - not that of the content > displayed within that container. In all the cases outlined by Ian, the > IFRAMEs stay on screen, it's just that the content gets scrolled. I don't think that's secure. The outer page can set the IFRAME's URL to contain a #xyz fragment identifier, scrolling the 'xyz' element into view for any element with id 'xyz'; for many pages, this could allow the outer page great flexibility in scrolling the framed content to a desired position. That gives you the same visual effect as moving the top-left of the container off the screen (especially if you add "scrolling=no" to the IFRAME so scrollbars are suppressed), so it should be treated the same way. I suppose you could handle that by disabling input to the IFRAME while its URL has a fragment identifier. But that doesn't work because AJAXy pages like to store state in the fragment identifier. So you need to disable input to the IFRAME while its URL has a fragment identifier that was set by the outer page. Ugh. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, Sep 30, 2008 at 11:16 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Tue, 30 Sep 2008, Robert O'Callahan wrote: > > > > > > I don't think this would really work for Google. Many widgets (e.g. > > > the mapping widget) are expected to be placed on any site, but how > > > could the widget provider know who is evil and who isn't? What about > > > if an otherwise not evil site is compromised? (This happens regularly, > > > especially with, e.g., sites with forum software or blog software.) We > > > don't want a vulnerability in a widget host site to immediately allow > > > this kind of attack on all the widgets that that site hosts. > > > > Choose your friends carefully. > > I'm not sure how that helps here. Are you saying widget providers > shouldn't do business with site owners who use popular blogging tools? > I'm saying that widget providers shouldn't let privileged UI be framed by sites they don't trust to do their job right. Maybe that sounds harsh. But of course it's less harsh than the reality of the situation we find ourselves in today. > But really, why does this mapping widget need to expose UI that can be > > abused to do evil things with my Google account? > > In the case of the mapping widget it doesn't, but consider a chat widget, > that enables users to chat with the site owner. If this widget had a > button that sent a message, a hostile site could perform a DDOS attack on > the site owner by embedding the widget host itself in an iframe, and > aligning everything such that all the users tricked into going to that > page and logged in to the chat widget would cause the victim site owner to > get messaged, potentially resulting in thousands of such messages. In this example, the site owner is at fault because they should have ensured that their widget-hosting page was not frameable by the hostile site. So it doesn't show a weakness in the model. So far in this discussion, we have a shortage of examples where a gadget has to be widely embeddable, and it has to have UI that triggers privileged operations, and those operations have to enable harmful consequences to agents other than the embeddor, and opening a new window or tab to confirm those operations is unreasonable. These are the examples that demand elaborate "option 3" measures. Since the claim is that these examples are common, I'd like to know more about them. > > > Secondly, consider Google Image Search, or Reddit with its "open link > > > with reddit toolbar" option, or any other site that allows arbitrary > > > Web navigation in a frame or iframe while hosting some sort of toolbar > > > content from its own page in another frame or container page. This > > > option would mean that many sites would stop working with these > > > containers, despite these containers not doing anything evil (there's > > > no overlapping content, the user is fully aware of what's going on, > > > etc). > > > > If I understand correctly, with Michal's option 3, those sites would > > also stop working as soon as the user scrolled down in the framed page > > (so that the top-left of the framed page is out of view). > > Any solution that breaks those sites is a non-starter IMHO. > Apparently "option 3" doesn't break them, although I have some questions about that. But it seems strange to say that breaking such sites is a "non-starter". Suppose a major browser added support for universal Origin headers and Access Controls and some kind of "Requires-Access-Controls" server header. If I run a site and I care about security and I don't care about being framed in Google Image Search or these other framing sites (assuming they don't drive much traffic to my site, or at least the parts of my site I want to protect) --- why shouldn't I welcome these measures and deploy them? Are you saying it would be irresponsible of browser vendors to support such features, because it would allow selfish behaviour of some sites to disrupt services provided by third parties? Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sep 29, 2008, at 9:42 PM, Ian Hickson wrote: On Mon, 29 Sep 2008, Maciej Stachowiak wrote: On Sep 28, 2008, at 3:32 AM, Robert O'Callahan wrote: I'm suggesting just reusing the Access Controls spec for that. So for example, the server could say: Same-Origin-Only-Unless-Access-Controls-Says-Otherwise: yes Access-Control-Allow-Origin: http://example.com I think this is a really good proposal. It would allow Web sites to place all content under a single uniform policy for access control, as opposed to the state today where cross-site access depends on how the resource is embedded. I don't think this would really work for Google. Many widgets (e.g. the mapping widget) are expected to be placed on any site, but how could the widget provider know who is evil and who isn't? What about if an otherwise not evil site is compromised? (This happens regularly, especially with, e.g., sites with forum software or blog software.) We don't want a vulnerability in a widget host site to immediately allow this kind of attack on all the widgets that that site hosts. Secondly, consider Google Image Search, or Reddit with its "open link with reddit toolbar" option, or any other site that allows arbitrary Web navigation in a frame or iframe while hosting some sort of toolbar content from its own page in another frame or container page. This option would mean that many sites would stop working with these containers, despite these containers not doing anything evil (there's no overlapping content, the user is fully aware of what's going on, etc). I did not think of that. But I don't think there has been a solution proposed yet that wouldn't break some content under some circumstances. This proposal at least has the advantage of not involving the layout code in security policy. Regards, Maciej
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, 30 Sep 2008, Robert O'Callahan wrote: > > > > I don't think this would really work for Google. Many widgets (e.g. > > the mapping widget) are expected to be placed on any site, but how > > could the widget provider know who is evil and who isn't? What about > > if an otherwise not evil site is compromised? (This happens regularly, > > especially with, e.g., sites with forum software or blog software.) We > > don't want a vulnerability in a widget host site to immediately allow > > this kind of attack on all the widgets that that site hosts. > > Choose your friends carefully. I'm not sure how that helps here. Are you saying widget providers shouldn't do business with site owners who use popular blogging tools? > But really, why does this mapping widget need to expose UI that can be > abused to do evil things with my Google account? In the case of the mapping widget it doesn't, but consider a chat widget, that enables users to chat with the site owner. If this widget had a button that sent a message, a hostile site could perform a DDOS attack on the site owner by embedding the widget host itself in an iframe, and aligning everything such that all the users tricked into going to that page and logged in to the chat widget would cause the victim site owner to get messaged, potentially resulting in thousands of such messages. This isn't really that hypothetical, either. Such chat widgets are starting to appear. I think we need to consider that such widgets will become common and could easily be vulnerable to this kind of thing, and should be protected. > > Secondly, consider Google Image Search, or Reddit with its "open link > > with reddit toolbar" option, or any other site that allows arbitrary > > Web navigation in a frame or iframe while hosting some sort of toolbar > > content from its own page in another frame or container page. This > > option would mean that many sites would stop working with these > > containers, despite these containers not doing anything evil (there's > > no overlapping content, the user is fully aware of what's going on, > > etc). > > If I understand correctly, with Michal's option 3, those sites would > also stop working as soon as the user scrolled down in the framed page > (so that the top-left of the framed page is out of view). Any solution that breaks those sites is a non-starter IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Placeholder option for text input boxes
Benjamin Hawkes-Lewis wrote: Garrett Smith wrote: |placeholder| sounds a little like |alt|. Alt is a property and an attribute on INPUT. How is placeholder content for a form field alternative text? The alt text is for situations where the can not be displayed at all. For example an where the image fails to load or the user has disabled. Or you could imagine in theory if the UA supported turning off form controls entirely. The placeholder is content that is displayed along with a rendered form control. Thus placeholder is used along with the form control, alt is used instead of it. / Jonas
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, 30 Sep 2008, Robert O'Callahan wrote: If I understand correctly, with Michal's option 3, those sites would also stop working as soon as the user scrolled down in the framed page (so that the top-left of the framed page is out of view). Nope, the restriction applies strictly to the top-left corner of the *container* getting scrolled of the screen - not that of the content displayed within that container. In all the cases outlined by Ian, the IFRAMEs stay on screen, it's just that the content gets scrolled. [ The only thing that #3 tries to prevent is having a cross-domain IFRAME positioned with CSS at negative screen offsets or with negative margins / padding, then carefully set IFRAME height and width, to effectively "crop" whatever is left displayed on screen. This is a weaker, but still plausible variant of the attack. ] /mz
Re: [whatwg] Placeholder option for text input boxes
I do not like this idea at all. That is what LABEL is for, and disappearing "it's so kewl" text is as annoying as BLINK and BGSOUND. Chris The tag is great for labels that are displayed outside the input box (in front of, above, etc.). The placeholder attribute is intended more as a hint than a label, and is displayed inside the input box without taking up any additional space on the page. An example might be: Get local weather forecast: Using the "alt" attribute has been suggested here, but no implementation uses "alt" in this way, while "placeholder" is already supported by one major browser (and since it really isn't alternate text, using "alt" doesn't make any sense). Another suggestion was to use the "title" attribute, which is a better idea, but "title" is generally implemented as a tooltip that doesn't appear until you hover over the element, which is not the desired behavior. It's perfectly legitimate to use a tag AND title AND placeholder attributes, for three subtly different purposes. You may find the behavior annoying, but hundreds if not thousands of popular sites are attempting to implement this behavior (via JavaScript and CSS) right now, and many of them are doing it badly. If it turns out to be just an annoying fad like was, then usage will fade away, for the same reason that we don't see much blinking text anymore even though "text-decoration: blink;" is still fully supported CSS. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, Sep 30, 2008 at 5:42 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Mon, 29 Sep 2008, Maciej Stachowiak wrote: > > On Sep 28, 2008, at 3:32 AM, Robert O'Callahan wrote: > > > > > > I'm suggesting just reusing the Access Controls spec for that. > > > > > > So for example, the server could say: > > > Same-Origin-Only-Unless-Access-Controls-Says-Otherwise: yes > > > Access-Control-Allow-Origin: http://example.com > > > > I think this is a really good proposal. It would allow Web sites to > > place all content under a single uniform policy for access control, as > > opposed to the state today where cross-site access depends on how the > > resource is embedded. > > I don't think this would really work for Google. Many widgets (e.g. the > mapping widget) are expected to be placed on any site, but how could the > widget provider know who is evil and who isn't? What about if an otherwise > not evil site is compromised? (This happens regularly, especially with, > e.g., sites with forum software or blog software.) We don't want a > vulnerability in a widget host site to immediately allow this kind of > attack on all the widgets that that site hosts. > Choose your friends carefully. But really, why does this mapping widget need to expose UI that can be abused to do evil things with my Google account? Secondly, consider Google Image Search, or Reddit with its "open link with > reddit toolbar" option, or any other site that allows arbitrary Web > navigation in a frame or iframe while hosting some sort of toolbar content > from its own page in another frame or container page. This option would > mean that many sites would stop working with these containers, despite > these containers not doing anything evil (there's no overlapping content, > the user is fully aware of what's going on, etc). > If I understand correctly, with Michal's option 3, those sites would also stop working as soon as the user scrolled down in the framed page (so that the top-left of the framed page is out of view). Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Canvas performance issue: setting colors
On Sep 30, 2008, at 1:09 AM, Sjoerd Visscher wrote: I guess this applies to the other methods and attributes of canvas as well. The majority of canvas methods are constructed in a way that allows an almost direct mapping to a C/C++ call. So when all the canvas code is perfectly optimized, the color code will probably still be the bottleneck. Unless you say that serializing floats to string and concatenating them and then parsing the string again can be done just as fast as creating and destructing a color object. Sorry, i'm not sure i understand what you're saying? The issue with your suggestion is that it would probably not save anything too dramatic in terms of performance -- you go from constructing a string which all js interpreters do optimise heavily to a function call + (from the PoV of the interpreter) generic object creation. For what you want (which is rapidly changing computed colours) a set*Style(double r, double g, double b, double a)-esque method -- creating an object you are unlikely to be reusing is superfluous. Anyhoo, the current unnecessary performance cost in the WebKit canvas implementation in this particular testcase is that we don't special case the common case (from the PoV of canvas) rgb[a](...) syntax and just fire up a full CSS compatible colour parser. The reality is that this is only really a significant problem for pages that do "bit blitting" by drawing millions of 1x1px rect fills where each rect fill has an colour parsing step. --Oliver On Sep 30, 2008, at 12:53 AM, Oliver Hunt wrote: I think the canvas api should get 2 new methods: CanvasColor createRGBAColor(in float r, in float g, in float b, in float a) CanvasColor createHSLAColor(in float h, in float s, in float l, in float a) WebKit already has a non-standard function -- setFillColor(r, g, b, a) -- that provides a faster mechanism to set the colour, however we believe we can rather easily improve the performance of the standard fillStyle, strokeStyle properties and just have not yet gotten round to it. Until we have improved this I would be hesitant to go around adding entirely new object types (especially canvas specific ones). --Oliver -- Sjoerd Visscher [EMAIL PROTECTED]
Re: [whatwg] Canvas performance issue: setting colors
I guess this applies to the other methods and attributes of canvas as well. The majority of canvas methods are constructed in a way that allows an almost direct mapping to a C/C++ call. So when all the canvas code is perfectly optimized, the color code will probably still be the bottleneck. Unless you say that serializing floats to string and concatenating them and then parsing the string again can be done just as fast as creating and destructing a color object. On Sep 30, 2008, at 12:53 AM, Oliver Hunt wrote: I think the canvas api should get 2 new methods: CanvasColor createRGBAColor(in float r, in float g, in float b, in float a) CanvasColor createHSLAColor(in float h, in float s, in float l, in float a) WebKit already has a non-standard function -- setFillColor(r, g, b, a) -- that provides a faster mechanism to set the colour, however we believe we can rather easily improve the performance of the standard fillStyle, strokeStyle properties and just have not yet gotten round to it. Until we have improved this I would be hesitant to go around adding entirely new object types (especially canvas specific ones). --Oliver -- Sjoerd Visscher [EMAIL PROTECTED]
[whatwg] Simplified WebSockets
It occurred to me the other day when musing on WebSockets that the
handshake is more complicated than required to achieve its purpose and
still allows potential exploits. I'm going to assume for now the purpose
of the handshake is to:
* Prevent unsafe communication with a non-websocket service.
* Provide just enough HTTP compatibility to allow proxying and virtual
hosting.
I think the case has been successfully put that DDOS or command
injection are possible using IMG tags or existing javascript methods -
however the counter-argument has been made that the presence of legacy
issues is not an argument for creating new ones. So with that in mind we
should implement WebSockets as robustly as we can.
Since we don't at first know what the service is we really need to
assume that:
* Long strings or certain characters may crash the service.
* The service may not be line orientated.
* The service may use binary data for communications, rather than text.
* Characters outside the ASCII printable range may have special meaning
(ie, 'bell' or control characters).
* No string is safe, since the service may use string commands and
non-whitespace separators.
For the sake of argument we'll assume the existence of a service that
accepts commands as follows (we'll also assume the service ignores bad
commands and continues processing):
AUTHENTICATE(user,password);GRANT(user,ALL);DELETE(/some/record);LOGOUT;
To feed this command set to the service via WebSockets we use:
var ws = new
WebSocket("http://server:1024/?;AUTHENTICATE(user,password);GRANT(user,ALL);DELETE(/some/record);LOGOUT;")
I have already verified that none of these characters require escaping
in URLs. The current proposal is fairly strict about allowed URIs but in
my opinion it is not strict enough. We really need to verify we are
talking to a WebSocket service before we start sending anything under
the control of a malicious author.
Now given the huge variety of non-HTTP sub-systems we'll be talking to I
don't think a full URL or path is actually a useful part of the
handshake. What does path mean to a mail server for instance?
Here is my proposal:
C = client
S = service
# First we talk to our proxy, if configured. We know we're talking to a
proxy because it's set on the client.
C> CONNECT server.example.com:1024 HTTP/1.1
C> Host: server.example.com:1024
C> Proxy-Connection: Keep-Alive
C> Upgrade: WebSocket/1.0
# Without a proxy we send
C> HEAD server.example.com:1024 HTTP/1.1
C> Host: server.example.com:1024
C> Connection: Keep-Alive
C> Upgrade: WebSocket/1.0
# If all goes well the service will respond with:
S> HTTP/1.1 200 OK
S> Upgrade: WebSocket/1.0
or
S> Some other HTTP response (but no Upgrade header)
or
S> Other non-HTTP response
or
No response.
# If we get a 200 response with Upgrade: WebSocket we *know* we have a
WebSocket. Any other response and the client can throw a 'Connection
failed' or 'Timeout' exception.
The client and server can now exchange any authentication tokens, access
conditions, cookies, etc according to service requirements. eg:
ws.Send( 'referrer=' + window.location + '\r\n' );
ws.Send( 'channel=' + 'customers' + '\r\n' );
ws.Send( CookiesToServerSyntax() );
The key advantages of this method are:
* Simplicity (less handshaking, less parsing, fewer requirements)
* Security (No page author control over initial handshake beyond the
server name or IP. Removes the risk of command injection via URI.)
* Compatibility (HTTP compatible. Proxy and Virtual Hosting compatible.
Allows a CGI script to emulate a WebSocket)
I'm not saying the current proposal doesn't provide some of these
things, just that I believe this proposal does it better.
Shannon
Re: [whatwg] Placeholder option for text input boxes
Garrett Smith wrote: |placeholder| sounds a little like |alt|. Alt is a property and an attribute on INPUT. How is placeholder content for a form field alternative text? -- Benjamin Hawkes-Lewis
