n see, the
only option in this situation 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
found the behaviour of the element 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
> wrote:
> [snip]
>> I expected (incorrectly, in this case) tha
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.
Foo
Foo
Cheers,
Kit Grose
User Experience + Tech Director,
iQmultimedia
(02) 4260 7946
k...@iqmultimedia.com.au
iqmultimedia.com.au
On 28/10/2009, at 1:10 PM, Aryeh Gregor wrote:
> On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose 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
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 (giv
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 additio
> 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
> Block-level in what sense? is not block-level in any sense; One
> could argue that and 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 saying "any e
> 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,
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&#x
a
DirectShow (theoretically enabling any codec the user has installed), but
that's pure speculation on my part.
—Kit Grose
tralia
but might be too restrictive for some other cultures.
Cheers,
Kit Grose
User Experience + Tech Director,
iQmultimedia
(02) 4260 7946
k...@iqmultimedia.com.au
iqmultimedia.com.au
ted in a way that implies selectable
content is, I believe, chiefly due to the lack of support for a "right" way to
do this (which has led many developers to implement the placeholder text simply
by setting the field's value to the placeholder text as the simplest
implementation).
Kit Grose
User Experience + Tech Director,
iQmultimedia
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 c
ly) currently do for their browser
chrome.
Kit Grose
User Experience + Tech Director,
iQmultimedia
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
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 tha
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 in
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" wrote:
> How would the "browser" assist you? Would you start to type in "new
> yor" and
ension to the tag (autocomplete 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 wrote:
>> System address
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 semanti
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 addition
idation pattern 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 mo
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 G
On 10/08/2010, at 10:44 AM, Tab Atkins Jr. wrote:
> On Mon, Aug 9, 2010 at 5:41 PM, Ryosuke Niwa wrote:
>> On Mon, Aug 9, 2010 at 8:36 AM, Andy Mabbett
>> wrote:
>>>
>>> On Mon, August 9, 2010 15:10, Daniel Glazman wrote:
>>>> Le 09/08/10 03:11, Kit
On 21/08/2010, at 3:21 PM, Adam Barth wrote:
> On Fri, Aug 20, 2010 at 7:25 PM, Robert O'Callahan
> wrote:
>> On Sat, Aug 21, 2010 at 8:24 AM, Ian Hickson wrote:
>>> One comment: Rather than adding an "allowfullscreen" attribute on
>>> , I would suggest just assuing that sandboxed content (i.e.
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
the spec, so on that logic, I think establishing a declarative fallback
mechanism is probably required to prevent a situation where you cannot write a
robust HTML5 page with video and without resorting to JS.
—Kit Grose
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
>> supp
31 matches
Mail list logo
