the current phrasing of the specification which cedes that
decision to implementors. This provides each implementor the latitude to
implement the placeholder behaviour in a way that is consistent with the
platform it's running on, as they (presumably) currently do for their browser
chrome.
Kit
On 20/03/2013, at 8:18 PM, Markus Ernst wrote:
Am 20.03.2013 02:20 schrieb Kit Grose:
In almost every case the placeholder remains visible until the user has
begun typing, as I strongly believe it ought to be remain in the
specification, since it provides the contextual hint for as long
to the placeholder text as the simplest
implementation).
Kit Grose
User Experience + Tech Director,
iQmultimedia
On 06/06/2012, at 7:44 AM, Ian Hickson wrote:
On Fri, 13 Jan 2012, Kit Grose wrote:
I'd argue that while we did receive in WebM a common codec it does not
enjoy the sort of universal adoption required to be able to mandate its
support in the spec, so on that logic, I think establishing
is probably required to prevent a situation where you cannot write a
robust HTML5 page with video and without resorting to JS.
—Kit Grose
Possibly an even more generic case for this would be when an anchor tag's href
attribute points to the current URL, allowing for any type of content (article
or otherwise) to get simple active nav item selection.
Cheers,
Kit Grose
User Experience + Technical Director
iQmultimedia
On 07/05
On 21/08/2010, at 3:21 PM, Adam Barth wrote:
On Fri, Aug 20, 2010 at 7:25 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sat, Aug 21, 2010 at 8:24 AM, Ian Hickson i...@hixie.ch wrote:
One comment: Rather than adding an allowfullscreen attribute on
iframe, I would suggest just assuing
On 10/08/2010, at 10:44 AM, Tab Atkins Jr. wrote:
On Mon, Aug 9, 2010 at 5:41 PM, Ryosuke Niwa ryosuke.n...@gmail.com wrote:
On Mon, Aug 9, 2010 at 8:36 AM, Andy Mabbett a...@pigsonthewing.org.uk
wrote:
On Mon, August 9, 2010 15:10, Daniel Glazman wrote:
Le 09/08/10 03:11, Kit Grose
How is a year input any different from a four-digit input type=number
field? Jakob Nielsen's testing has shown that forcing users to enter dates
using drop-down menus (or any other non-textual input) is a mistake:
http://www.useit.com/alertbox/20001112.html
I'm not sure what sort of additional
on a standard text field.
—Kit
On 09/08/2010, at 10:46 AM, Andy Mabbett wrote:
On Mon, August 9, 2010 00:44, Kit Grose wrote:
How is a year input any different from a four-digit input type=number
field?
Years can be more of fewer than four digits. Julius Caesar was born in 100
BC, for instance
On 09/08/2010, at 11:49 AM, Jonathan Castello wrote:
Couldn't the BC/AD case be handled intuitively by a dropdown right
next to the year field that contains those two options?
Do you consider your own birth year to be, e.g., 1970 AD? Why stop there—do
we need to also distinguish between
I do see an advantage to permitting the arbitrary styling of the BR element.
Often a series of links shown inline are separated by a pipe (|) character. In
the past I've produced this effect using border-right and other such malarky on
the anchors or inline LIs with the same, but I think
System address book, perhaps?
Cheers,
Kit Grose
User Experience + Technical Director
iQmultimedia
+61 (0)2 4260 7946
On 19/06/2010, at 12:48 PM, Adam Shannon a...@ashannon.us wrote:
How would the browser assist you? Would you start to type in new
yor and it would drop down a list giving
if possible using the UA's
knowledge of such-and-such).
—Kit
On 19/06/2010, at 1:25 PM, Adam Shannon wrote:
So, each person will be responsible for updating the address book?
On Fri, Jun 18, 2010 at 21:49, Kit Grose k...@iqmultimedia.com.au wrote:
System address book, perhaps?
Cheers,
Kit
On 16/04/2010, at 5:06 PM, Markus Ernst wrote:
Is it not possible to say the autofocus attribute is readonly? It dose
IMO not make sense to apply it via scripting, as focus() is available
for scripting.
What if the form is received via XHR as HTML and simply injected to the page
using
On 16/04/2010, at 9:08 AM, Jonas Sicking wrote:
While we could deploy a bunch of heuristics, it seems much simpler to
just say that it is the *first* element with autofocus that should
receive focus. I can't think of any significant downsides with this.
I agree with you both generally, but I
On 16/04/2010, at 10:54 AM, Jonas Sicking wrote:
Worse, the spec (IMHO rightly) suggests that if the user is already
interacting with another part of the page, the autofocus attribute
should be ignored. So in this case the 'compose' link will be focused,
and so the UA should IMHO assume that
.
Cheers,
Kit Grose
User Experience + Tech Director,
iQmultimedia
(02) 4260 7946
k...@iqmultimedia.com.au
iqmultimedia.com.au
installed), but
that's pure speculation on my part.
—Kit Grose
On 05/02/2010, at 8:08 AM, David Singer wrote:
On Feb 3, 2010, at 15:03 , Kit Grose wrote:
I feel that the user shouldn't have the ability to enter into some sort of
pseudo-fullscreen. If the content needs to be displayed full-screen,
I don't believe that there is any such 'need
Another scenario applies to most video player sites. Almost all video player
sites using Flash have a full screen button. Many of them do not have a full
window button, however. If a user wishes to view content scaled up to fill
the window, without the distractions of navigational links,
1) Should be convenient for authors to make any element in a page display
fullscreen
2) Should support in-page activation UI for discoverability
3) Should support changing the layout of the element when you enter/exit
fullscreen mode. For example, authors probably want some controls to be
Block-level in what sense? img is not block-level in any sense; One
could argue that video and object are block-level in HTML terms,
but it's context-dependent (they can contain blocks if their parent
can). None of these are block-level in the CSS sense, by default.
True, but surely
I agree with Aryeh in principle; when you're updating the suggestions on every
keypress, extra processing and DOM manipulation at the Javascript level would
be good to avoid.
As far as Aryeh's lack of other use-cases for comboboxes in general, a good
place to use one would be for inline
It seems counterintuitive to me that having produced fallback content
already, I still need to use Javascript to test for compatibility
(even if I *did* generate two formats, there's obviously no guarantee
IE9 won't come out requiring WMV or a similar issue with a different
UA).
Are there
On 04/12/2009, at 1:13 AM, Philip Jägenstedt wrote:
I'll freely admit that the most important reason I oppose this is
because
I don't want to implement it
And I'll admit that the main reason I support it is selfish on my part
too :).
Basically I don't want to be producing OGG files (given
On 28/10/2009, at 1:10 PM, Aryeh Gregor wrote:
On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose k...@iqmultimedia.com.au wrote:
Can I get some sort of an understanding on why this behaviour (non-
descript error in supported UAs rather than using the fallback content
that can provide alternate
div
img /
/div
captionFoo/caption
/figure
figure
div
img /
/div
div
captionFoo/caption
/div
/figure
Cheers,
Kit Grose
User Experience + Tech Director,
iQmultimedia
(02) 4260 7946
k
is to rely on Javascript and the video
element's canPlayType() function.
Can I get some sort of an understanding on why this behaviour (non-
descript error in supported UAs rather than using the fallback content
that can provide alternate access methods) would be preferred?
Cheers,
Kit Grose
User
highly contrary to what I
had expected and wanted to raise it as a concern.
—Kit
On 28/10/2009, at 12:28 PM, Gregory Maxwell wrote:
On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose k...@iqmultimedia.com.au
wrote:
[snip]
I expected (incorrectly, in this case) that if I only produced one
source
Thanks for the really in-depth reply; you make some excellent points
(particularly defining a video source file with the src attribute). I
think it all boils down to the fact that canPlayType() can return
maybe; and in those cases the expected behaviour I mention isn't
easily definable.
31 matches
Mail list logo
