Hi Anne,
Great to see that this is being worked on! And it's great to see that
it enables integration with built-in share functionality provided by
the UA. I also *really* like the idea of integrating with save as
and input type=file.
However there's a couple of use cases that seems good to
Roger Hågensen resca...@emsai.net writes:
I just checked WHATWG HTML5 and rel=bookmark isn't there at all (I
didn't check W3C HTML5 though).
The section on the bookmark link type in WHATWG HTML can be found here:
https://html.spec.whatwg.org/multipage/semantics.html#link-type-bookmark
The
Roger Hågensen resca...@emsai.net writes:
Which brings another issue, how far is too far? Should the naming be
standardized as well?
Right click a URL on a page and what do you see?
Chrome shows Copy link adress
Firefox shows Bookmark This Link and Copy Link Location
IE shows Add to
Hi,
Chrome already ignores the prevalent autocomplete=off for password
fields. We plan to ignore this tag for Autofill (addresses, credit cards)
fields as well. autocomplete=off will still be respected for autocomplete
data (e.g. past searches on crbug.com).
We think this will break a very small
On 2014-11-13 18:11, Nils Dagsson Moskopp wrote:
Roger Hågensen resca...@emsai.net writes:
I just checked WHATWG HTML5 and rel=bookmark isn't there at all (I
didn't check W3C HTML5 though).
The section on the bookmark link type in WHATWG HTML can be found here:
On 2014-11-13 18:19, Nils Dagsson Moskopp wrote:
AFAIK, all of these interface details lie outside the scope of the
HTML specification (and rightly so, IMHO). If you need a standard
symbol for bookmarks I suggest to use U+1F516 BOOKMARK, which looks
like this „“.
Then don't spec it but
On 2014-11-13 20:20, Evan Stade wrote:
Currently this new behavior is available behind a flag. We will soon be
inverting the flag, so you have to opt into respecting autocomplete=off.
I don't like that browsers ignore HTML functionality hints like that.
I have one real live use case that
On Thu, Nov 13, 2014 at 7:17 PM, Roger Hågensen resca...@emsai.net wrote:
On 2014-11-13 20:20, Evan Stade wrote:
Currently this new behavior is available behind a flag. We will soon be
inverting the flag, so you have to opt into respecting autocomplete=off.
I don't like that browsers
On 2014-11-14 02:49, Glenn Maynard wrote:
On Thu, Nov 13, 2014 at 7:17 PM, Roger Hågensen resca...@emsai.net wrote:
I have one real live use case that would be affected by this.
http://player.gridstream.org/request/
Unfortunately, even if a couple pages have a legitimate use for a feature,
If the site sets autocomplete=off could you disable the saving of new
suggestions? One of the main use cases for turning off autocomplete is to
disable the saving of sensitive or irrelevant information. If the user is
filling in an address or cc num it's likely they have the opportunity to save
On 2014-11-14 02:49, Glenn Maynard wrote:
Unfortunately, even if a couple pages have a legitimate use for a
feature, when countless thousands of pages abuse it, the feature needs
to go. The damage to people's day-to-day experience outweighs any
benefits by orders of magnitude.
Also, banks
On 2014-11-14 03:57, Ben Maurer wrote:
If the site sets autocomplete=off could you disable the saving of new
suggestions? One of the main use cases for turning off autocomplete is to
disable the saving of sensitive or irrelevant information. If the user is
filling in an address or cc num it's
(Trimming for time and to avoid exploding the thread. Others can respond
to the rest if they like.)
On Thu, Nov 13, 2014 at 8:26 PM, Roger Hågensen resca...@emsai.net wrote:
Punishing those who do it right because of the stupidity of the many,
can't say I'm too thrilled about that.
Leaving
Are you going to properly fire changeinput events when autofill happens?
The current autofill behavior is causing major headaches for application
and framework developers and by ignoring autocomplete attribute you disable
the only way developers can work around this bug.
On angular we had to
On 2014-11-14 04:30, Glenn Maynard wrote:
(Trimming for time and to avoid exploding the thread. Others can
respond to the rest if they like.)
No it's inherently correct for the use case as listeners tend to
enter things like:
Could you play Gun's'Rose?
Love you show, more
On Thu, Nov 13, 2014 at 9:03 PM, Roger Hågensen resca...@emsai.net wrote:
This is getting more off topic but... have you ever typed wrong and now
the autocomplete keeps listing your wrong spelling every time? And the only
way to fix it is to nuke all your data, there is no way to edit/control
On Thu, Nov 13, 2014 at 5:17 PM, Roger Hågensen resca...@emsai.net wrote:
On 2014-11-13 20:20, Evan Stade wrote:
Currently this new behavior is available behind a flag. We will soon be
inverting the flag, so you have to opt into respecting autocomplete=off.
I don't like that browsers
That sounds like crbug.com/354257 which was fixed in March. Are you sure
this is still a problem on newer versions of Chrome?
On Thu, Nov 13, 2014 at 8:22 PM, Igor Minar imi...@google.com wrote:
Are you going to properly fire changeinput events when autofill happens?
The current autofill
On 2014-11-14 08:02, Evan Stade wrote:
On Thu, Nov 13, 2014 at 5:17 PM, Roger Hågensen resca...@emsai.net wrote:
On 2014-11-13 20:20, Evan Stade wrote:
Currently this new behavior is available behind a flag. We will soon be
inverting the flag, so you have to opt into respecting
19 matches
Mail list logo
