On Feb 18, 2010, at 2:54 PM, L. David Baron wrote:
On Thursday 2010-02-18 16:45 -0600, Tab Atkins Jr. wrote:
Anne suggested in IRC using the pseudoclass approach, and pairing it
with the ::value pseudoelem from the Basic UI Module. You could get
But the key question (from the Webkit bug) is
On Feb 17, 2010, at 3:15 PM, Jonas Sicking wrote:
The reason this is a function rather than a read-only attribute is to
allow the return FormData to be further modified. I.e. the following
should be allowed:
fd = myFormElement.getFormData();
fd.append("foo", "bar");
xhr.send(fd);
If it was a
On Feb 18, 2010, at 8:36 PM, Tab Atkins Jr. wrote:
On Thu, Feb 18, 2010 at 10:28 PM, Maciej Stachowiak
wrote:
However, I also think 0-argument getters are a bad pattern in
JavaScript.
Why not just use an attribute?
interface HTMLFormElement : HTMLElement {
...
readonly attribute FormDat
On Thu, Feb 18, 2010 at 10:28 PM, Maciej Stachowiak wrote:
> However, I also think 0-argument getters are a bad pattern in JavaScript.
> Why not just use an attribute?
>
> interface HTMLFormElement : HTMLElement {
> ...
> readonly attribute FormData formData;
> ...
> };
Jonas addressed that in
On Feb 18, 2010, at 2:06 PM, Jonas Sicking wrote:
On Wed, Feb 17, 2010 at 11:30 PM, Anne van Kesteren
wrote:
On Thu, 18 Feb 2010 00:15:25 +0100, Jonas Sicking
wrote:
So I suggest we add a method like
interface HTMLFormElement : HTMLElement {
...
FormData getFormData();
...
};
Shoul
On Thu, 18 Feb 2010 21:20:38 -0500, Jonas Sicking wrote:
On Thu, Feb 18, 2010 at 5:30 PM, Robert O'Callahan
wrote:
On Fri, Feb 19, 2010 at 1:52 PM, Ian Hickson wrote:
toDataURL() was named that way for consistency with toString(), which
seems a closer analogue here than getElementById() a
On Thu, Feb 18, 2010 at 5:30 PM, Robert O'Callahan wrote:
> On Fri, Feb 19, 2010 at 1:52 PM, Ian Hickson wrote:
>>
>> toDataURL() was named that way for consistency with toString(), which
>> seems a closer analogue here than getElementById() and friends.
>
>
> But you're not really converting th
On Fri, 19 Feb 2010, Robert O'Callahan wrote:
> On Fri, Feb 19, 2010 at 1:52 PM, Ian Hickson wrote:
> >
> > toDataURL() was named that way for consistency with toString(), which
> > seems a closer analogue here than getElementById() and friends.
>
> But you're not really converting the form ele
On Fri, Feb 19, 2010 at 1:52 PM, Ian Hickson wrote:
> toDataURL() was named that way for consistency with toString(), which
> seems a closer analogue here than getElementById() and friends.
>
But you're not really converting the form element into something equivalent,
are you? That's what "to"
On Thu, 18 Feb 2010, Anne van Kesteren wrote:
> On Thu, 18 Feb 2010 23:06:12 +0100, Jonas Sicking wrote:
> > On Wed, Feb 17, 2010 at 11:30 PM, Anne van Kesteren
> > wrote:
> > > On Thu, 18 Feb 2010 00:15:25 +0100, Jonas Sicking
> > > wrote:
> > > >
> > > > So I suggest we add a method like
> >
On Thu, 2010-02-18 at 17:54 -0500, L. David Baron wrote:
> On Thursday 2010-02-18 16:45 -0600, Tab Atkins Jr. wrote:
> > Anne suggested in IRC using the pseudoclass approach, and pairing it
> > with the ::value pseudoelem from the Basic UI Module. You could get
>
> But the key question (from the
On Thu, Feb 18, 2010 at 4:54 PM, L. David Baron wrote:
> On Thursday 2010-02-18 16:45 -0600, Tab Atkins Jr. wrote:
>> Anne suggested in IRC using the pseudoclass approach, and pairing it
>> with the ::value pseudoelem from the Basic UI Module. You could get
>
> But the key question (from the Webk
On Thursday 2010-02-18 16:45 -0600, Tab Atkins Jr. wrote:
> Anne suggested in IRC using the pseudoclass approach, and pairing it
> with the ::value pseudoelem from the Basic UI Module. You could get
But the key question (from the Webkit bug) is really whether the UA
styles apply to the input itse
On Thursday 2010-02-18 17:40 -0500, L. David Baron wrote:
> I'd be inclined towards the pseudo-class, though, partly since that
> failure mode bothers me less, and partly since it's a lot simpler
> (maybe not to implement in one engine, but probably to implement
> interoperably and to specify, sinc
On Thu, Feb 18, 2010 at 4:40 PM, L. David Baron wrote:
> On Thursday 2010-02-18 16:21 -0600, Tab Atkins Jr. wrote:
>> Ah, got it.
>>
>> That doesn't seem like a horrible problem to me. Most people don't
>> set color on inputs, and when they do, it's at least guaranteed that
>> the color is *usabl
On Thursday 2010-02-18 16:21 -0600, Tab Atkins Jr. wrote:
> Ah, got it.
>
> That doesn't seem like a horrible problem to me. Most people don't
> set color on inputs, and when they do, it's at least guaranteed that
> the color is *usable* for placeholder, even if it's not ideal. They
> can just s
On 2/18/10 5:27 PM, L. David Baron wrote:
It doesn't need to be nearly as restricted as :first-line, since
it's tree-like. It's much more like :before and :after.
While true, I'm not sure it makes much sense to position, float, change
display of, etc the placeholder pseudo-element
-Bori
On 2/18/10 5:21 PM, Tab Atkins Jr. wrote:
That doesn't seem like a horrible problem to me. Most people don't
set color on inputs
I just checked that claim on a few sites (the first ones that came to
mind). Most of these are search fields; the rest are login fields.
These set input colors:
On Thursday 2010-02-18 13:58 -0600, Tab Atkins Jr. wrote:
> I agree that having a pseudoelement for the placeholder text is a good
> idea. Perhaps you could bring it up on the www-style list so we can
> decide precisely what properties should apply to it? It seems
> reasonable to apply the same r
On Thu, 2010-02-18 at 16:21 -0600, Tab Atkins Jr. wrote:
> Setting color:black without a
> background-color:white is distressingly common, but overall most
> inputs are unstyled in my experience.
That should throw up issues in a CSS validation check, as it really
screws up with both people like
On Thu, Feb 18, 2010 at 4:04 PM, Anne van Kesteren wrote:
> On Thu, 18 Feb 2010 22:54:38 +0100, Tab Atkins Jr.
> wrote:
>>
>> I can't quite parse your comment, Anne. What problems are you
>> referring to that involve default style rules? There's nothing in the
>> cited bug about that.
>
> Yes t
On Thu, 2010-02-18 at 17:07 -0500, Boris Zbarsky wrote:
> On 2/18/10 4:54 PM, Ashley Sheridan wrote:
> > What about a new selector for these sorts of elements?
>
> The topic of this thread is what form this selector should take and how
> it should work.
>
> > To me it seems logical that you
> >
On Thu, 18 Feb 2010 23:06:12 +0100, Jonas Sicking wrote:
On Wed, Feb 17, 2010 at 11:30 PM, Anne van Kesteren
wrote:
On Thu, 18 Feb 2010 00:15:25 +0100, Jonas Sicking
wrote:
So I suggest we add a method like
interface HTMLFormElement : HTMLElement {
...
FormData getFormData();
...
};
On 2/18/10 4:54 PM, Ashley Sheridan wrote:
What about a new selector for these sorts of elements?
The topic of this thread is what form this selector should take and how
it should work.
To me it seems logical that you
shouldn't be using pseudo elements
Why? If what you're trying to style
On Wed, Feb 17, 2010 at 11:30 PM, Anne van Kesteren wrote:
> On Thu, 18 Feb 2010 00:15:25 +0100, Jonas Sicking wrote:
>>
>> So I suggest we add a method like
>>
>> interface HTMLFormElement : HTMLElement {
>> ...
>> FormData getFormData();
>> ...
>> };
>
> Should we name it toFormData() instea
On Thu, 18 Feb 2010 22:54:38 +0100, Tab Atkins Jr.
wrote:
I can't quite parse your comment, Anne. What problems are you
referring to that involve default style rules? There's nothing in the
cited bug about that.
Yes there is, but you have to follow the links ;-):
https://bugs.webkit.org/
On 2/18/10 4:48 PM, Anne van Kesteren wrote:
Can we really not try to push this as pseudo-class and educate the
masses?
I'm not sure what you're proposing. Something like
"input:has-placeholder-showing"? (I guess webkit tried
":-webkit-input-placeholder-mode".)
UAs could do some trickery
On Thu, 2010-02-18 at 22:48 +0100, Anne van Kesteren wrote:
> On Thu, 18 Feb 2010 17:29:14 +0100, Mounir Lamouri
> wrote:
> > I am working on placeholder implementation on Gecko and I am face of the
> > placeholder style customization. Indeed, a website can style the
> > input/textearea element
On Thu, Feb 18, 2010 at 3:48 PM, Anne van Kesteren wrote:
> On Thu, 18 Feb 2010 17:29:14 +0100, Mounir Lamouri
> wrote:
>>
>> I am working on placeholder implementation on Gecko and I am face of the
>> placeholder style customization. Indeed, a website can style the
>> input/textearea element whi
On Thu, 18 Feb 2010 17:29:14 +0100, Mounir Lamouri
wrote:
I am working on placeholder implementation on Gecko and I am face of the
placeholder style customization. Indeed, a website can style the
input/textearea element which can make default placeholder style
inappropriate.
The trivial idea is
On Thu, Feb 18, 2010 at 10:29 AM, Mounir Lamouri
wrote:
> Hi,
>
> I am working on placeholder implementation on Gecko and I am face of the
> placeholder style customization. Indeed, a website can style the
> input/textearea element which can make default placeholder style
> inappropriate.
> The tr
On Thu, Feb 18, 2010 at 12:41 PM, Tim Hutt wrote:
> Good point. You mean something like a .ram file? I think both
> techniques should be supported -- a metadata file is extra hassle to
> set up if you /are/ the HTML and video author, and it involves an
> extra file download which will slow things
Ian Hickson wrote:
> On Fri, 22 Jan 2010, Mike Wilson wrote:
> >
> > I'll keep this short as there is more recent discussion:
> > 2) The pageStorage object is one incarnation of [a key
> >value store] solving the dependency problem that appears
> >when different components want to save dat
On 17 February 2010 03:05, Conrad Parker wrote:
>> My point exactly. There is no single 'quality' metric, so the best we
>> can do is give the user agent the relevant information and let it
>> decide.
>
> Perhaps, but why are you suggesting that HTML is the correct place to
> offer that informatio
Hi,
I am working on placeholder implementation on Gecko and I am face of the
placeholder style customization. Indeed, a website can style the
input/textearea element which can make default placeholder style
inappropriate.
The trivial idea is to create a CSS pseudo-element to style the
placeholder.
[cross-posting as a similar amount of discussion has taken
place on the two groups]
Sebastian Hennebrueder wrote:
> The browser should generate an id unique per browser window
> and sent it as request header with every browser request.
> Request Header
> --
> X-Window-Id: 279078917624
36 matches
Mail list logo
