The video element currently supports only 3 possible values for
@preload attribute [1]. Real world user agent implementations agree on
keyword none only. Both metadata and auto have a pretty poor
interoperability, especially considering the amount of actual data
transferred if user never hits
As shown in [2], mobile browsers don't preload anything, which is OK
because the network fee is usually high.
Loading 25 seconds is the behavior of desktop Chrome, and I don't see
this as a big problem.
Static web pages probably don't have enough knowledge to determine how
much data the UA
On Fri, Mar 27, 2015 at 1:28 PM, Brett Zamir bret...@yahoo.com wrote:
Since fetch() is making life easier as is and in the spirit of promises, how
about taking it a step further to simplify the frequent use case of needing
to retrieve multiple resources and waiting for all to return?
If the
On Fri, Mar 27, 2015 at 1:50 PM, Brett Zamir bret...@yahoo.com wrote:
Thanks, I realize it's doable that way, but I think it makes for less
distracting code when the implementation details of the map call and such
are avoided for something as basic as loading resources...
Write a function that
Since fetch() is making life easier as is and in the spirit of promises,
how about taking it a step further to simplify the frequent use case of
needing to retrieve multiple resources and waiting for all to return?
If the first argument to fetch() could be an array, then fetch() could
be made
On 3/27/2015 8:39 PM, Anne van Kesteren wrote:
On Fri, Mar 27, 2015 at 1:28 PM, Brett Zamir bret...@yahoo.com wrote:
Since fetch() is making life easier as is and in the spirit of promises, how
about taking it a step further to simplify the frequent use case of needing
to retrieve multiple
It's sad indeed, as it seems that best practices are seldomly followed and
poor coding is the way.
However,
some functionality ordinarily provided by JavaScript that now can be done
by HTML5, e.g. the details tag and progress tag
Actually progress is native only in its attribute definition and
On 03/27/2015 06:51 PM, Miles Fidelman wrote:
I've been reading through the discussion thread, all of which seems to
jump immediately into the weeds of specific details of the proposal.
I'm amazed that nobody has yet commented on the implicit premise, which
I read as:
- JavaScript is a
I'm (obviously) +1 on this.
Navs are great semantically, but very, very impractical as sectioning
content.
I'd rather see them being implemented more loosely. You can always add a
heading if that's justified or practical. But implying it forces the ugly
and pretty useless structure Andrea
I've been reading through the discussion thread, all of which seems to
jump immediately into the weeds of specific details of the proposal.
I'm amazed that nobody has yet commented on the implicit premise, which
I read as:
- JavaScript is a processing pig
- with the addition of a few,
After a mail confrontation with Reinier, as well as some very simple models
I saw at work, I have to admit that I support this idea.
nav has a strong semantic value, for sure. It deserves UAs to easily
highlight navigation elements.
Thus said, is it really needed that nav necessarily defines a
11 matches
Mail list logo
