- multiple autofocused elements per page are valid, but only one per form
Is it possible to focus on multiple elements at the same time even in
different forms? If they are both text boxes and a user types which
element gets the keyboard input?
Autofocus only really makes at load time - for any
This is an idea I've had in my head for a while and I think it might
make an useful addition to HTML5 standard.
As this is just an idea I didn't work out all the details. I'm just
looking to see if this is something that might be accepted.
Use case 1:
A document author wants to provide a link to
Use cases:
1) A screen reader that sees a form with a type=username and a
password field. The screen reader could just ask Log in to this site?
[y/n]?. No further context would be needed.
2) UAs can more easily discover login forms and offer things such as
Firefox's Account Manager [1] or a
?.
--
Eitan Adler
The way I see it is that instead of browsers traversing the DOM looking
for
an input field of either id=username or name=username or even
class=username, they now only have to look for an input of type username.
Makes it a lot easier for both developers and browser vendors as they now
only
input type=text pattern=email
input type=username pattern=email
What if for some strange reason I wanted to only allow the text
e-m-a-i-l ? There would have to be some way to differentiate between a
keyword and a normal pattern.
Please note there's a rather strong privacy issue here. I don't want a
web page to be able - without my prior consent - to query the list of
fonts available in my system.
You already have this problem if a website were to create a list of
elements with a list of different fonts and use
like
file:///home/eitan/file_to_upload.pdf
or
http://example.com/file.pdf
or
ftp://user:passw...@example.com/file.pdf
It would then be the server's job to fetch the file unless the user
passed it a file:// scheme it which case the file would be provided by
the UI.
--
Eitan Adler
url?
On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote:
It would then be the server's job to fetch the file unless the user
passed it a file:// scheme it which case the file would be provided by
the UI.
I imagine this would be a UI decision - not one made by the spec.
However I, with very
.
Eitan, have I understood your proposal correctly?
Yes - exactly.
--
Eitan Adler
on purpose in order to allow for an empty option
to be selected.
Perhaps the @requires attribute could be handled somewhat differently. If
present the default value becomes the not allowed value and the browser
would require you to change the value before submitting the form.
--
Eitan Adler
be entered either
manually or with some kind of map like interface.
These are two separate proposals and I both could co-exist one as
type=location and the other as type=gps
--
Eitan Adler
method of requesting a
map source
this source could be any existing map provider
Then again now that I think about it some more I don't see this
working out too well.
--
Eitan Adler
Seeing your 2c and raising you a citation needed. ;-)
But to the point at hand
Would the @pattern attribute cover the use case of lat/long inputs? (albeit
without a nice UI)
Possibly. I personally think that the UI is worth adding it to the spec.
--
Eitan Adler
a give web
application' ?
Take a look at
http://www.w3.org/TR/html5/offline.html
Specifically
http://www.w3.org/TR/html5/offline.html#manifests
--
Eitan Adler
, there's a good point: I would actually add this: if main or an
element with @role=main exist on the page, there is no need to run the
Scooby-Doo algorithm and that element can just be chosen as the main
element.
What if both exist but are different elements?
--
Eitan Adler
On 25 July 2016 at 14:59, Nils Dagsson Moskopp <
n...@dieweltistgarnichtso.net> wrote:
> Eitan Adler <li...@eitanadler.com> writes:
> > See also the remainder of my email.
>
> I do not understand. What do you mean?
>
Please re-read the original email of the threa
On 25 July 2016 at 13:32, Nils Dagsson Moskopp <
n...@dieweltistgarnichtso.net> wrote:
> Eitan Adler <li...@eitanadler.com> writes:
>
> > At the moment if you'd like the user to enter *only* digits (no
> separators,
> > +, -, etc.) you must resort to a h
in better error messages where the value to be
entered needs to be copied from somewhere, and so the minimum and maximum
are really proxies for length.
--
Eitan Adler
19 matches
Mail list logo
