[whatwg] Improving video preload?
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 play [2]. For example, current Chrome defaults to loading first 25 seconds of video even with value metadata. If one has high quality HD video as the source, 25 seconds may be around 20 MB which is pretty much above the size I would expect to contain only metadata. Would it be possible to allow data sizes in @preload attribute in addition to keywords? For example, video preload=100KB would preload the first 100 KB of video file if user never hits the play. Granted, this puts some additional burden on content authoring but it would allow having some preloading instead of currently available none for many services. Both auto and metadata load way too much to be usable in many user agents. While streaming, the preload amount should be assumed to mean additional buffering over the automatic buffering done by the UA. This would allow scripts to add extra buffer margins e.g. if user has previously experienced buffer underruns while viewing other videos on the same site. It might even make sense to support @preload with a numeric value without an unit as the count of kilobytes to preload. However, always requiring the unit would allow extending @preload with e.g. video preload=5s in the future. I personally don't like specifying preload amount as seconds because it requires first loading metadata to compute the actual amount to preload. In addition, the preloaded amount seldomly matches any second amount but actual available data transfer bandwidth, video bitrate and audio bitrate needs to be considered for skipless playback. [1] https://html.spec.whatwg.org/multipage/embedded-content.html#attr-media-preload [2] http://www.stevesouders.com/blog/2013/04/12/html5-video-preload/ -- Mikko
Re: [whatwg] Improving video preload?
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 should preload, because it depends on the network status and user's preference. So I think better solutions could be: 1) UAs allow user to specify how much data should be preloaded according to network status. 2) Add preloadData and preloadTime IDL properties to HTMLMediaElement to fine-tune the preload behavior, e.g. // preload at most 1000KB or 3 seconds, which comes first. video.preloadData = 1000; video.preloadTime = 3; In JS codes, authors are encouraged to set them after detecting the network status (e.g. https://developer.mozilla.org/en-US/docs/Web/API/Connection). Regards, Duan Yao 在 2015/3/27 18:43, Mikko Rantalainen 写道: 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 play [2]. For example, current Chrome defaults to loading first 25 seconds of video even with value metadata. If one has high quality HD video as the source, 25 seconds may be around 20 MB which is pretty much above the size I would expect to contain only metadata. Would it be possible to allow data sizes in @preload attribute in addition to keywords? For example, video preload=100KB would preload the first 100 KB of video file if user never hits the play. Granted, this puts some additional burden on content authoring but it would allow having some preloading instead of currently available none for many services. Both auto and metadata load way too much to be usable in many user agents. While streaming, the preload amount should be assumed to mean additional buffering over the automatic buffering done by the UA. This would allow scripts to add extra buffer margins e.g. if user has previously experienced buffer underruns while viewing other videos on the same site. It might even make sense to support @preload with a numeric value without an unit as the count of kilobytes to preload. However, always requiring the unit would allow extending @preload with e.g. video preload=5s in the future. I personally don't like specifying preload amount as seconds because it requires first loading metadata to compute the actual amount to preload. In addition, the preloaded amount seldomly matches any second amount but actual available data transfer bandwidth, video bitrate and audio bitrate needs to be considered for skipless playback. [1] https://html.spec.whatwg.org/multipage/embedded-content.html#attr-media-preload [2] http://www.stevesouders.com/blog/2013/04/12/html5-video-preload/
Re: [whatwg] Array as first argument to fetch()
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 first argument to fetch() could be an array, then fetch() could be made to work like Promise.all() and return an array of the results to then(). It seems easy enough to just write that yourself, e.g. Promise.all([image, script].map(url = fetch(url))) works fine in Firefox Nightly. -- https://annevankesteren.nl/
Re: [whatwg] Array as first argument to fetch()
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 abstracts it... If everyone opts to use that instead of fetch(), we can revisit. -- https://annevankesteren.nl/
[whatwg] Array as first argument to fetch()
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 to work like Promise.all() and return an array of the results to then(). Thanks, Brett
Re: [whatwg] Array as first argument to fetch()
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 resources and waiting for all to return? If the first argument to fetch() could be an array, then fetch() could be made to work like Promise.all() and return an array of the results to then(). It seems easy enough to just write that yourself, e.g. Promise.all([image, script].map(url = fetch(url))) works fine in Firefox Nightly. 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... Best, Brett
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
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 default rendering. It still requires JS in order to access its @value in write mode. On the other hand, I suppose that complete implementation of details is delayed by the fact that it's defined in terms of shadow DOM, and no real DOM adjusting is expected for it. Not every browser is ready for this further level of interface, probably. 2015-03-28 3:45 GMT+01:00 Michael A. Peters mpet...@domblogger.net: 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 processing pig - with the addition of a few, well-defined constructs to HTML, with support from browsers, we could do a lot of what we want (or what people are doing) - without the overhead imposed by JavaScript To me, this seems like a very good thing. It seems like: - It's getting harder and harder to do simple things. Too many JavaScript frameworks and libraries. Too much complexity. Authoring should not require extensive programming skills. (Whatever happened to the read/write web?). - JavaScript seems to encourage poor programming style, or at least resource-intensive programming. It seems like 2/3 of the web pages I visit either freeze up, or just take incredibly long to load. Granted, that a lot of this is this stems from all the little click monitoring apps, and widgets, and who knows what else people put on their pages - and waiting for those various sites to respond - but it's the proliferation of more and more JavaScript that enables this. In HTML5 some functionality ordinarily provided by JavaScript that now can be done by HTML5, e.g. the details tag and progress tag, is still not universally supported by modern browsers requiring JavaScript fallback. I don't know why it takes the browsers so long to implement, but it does. The problem with JavaScript is that fewer and fewer web devs care. Rather than picking a framework (like jQuery) and sticking with it, they copypasta JS they find around the web (often in violation of the license) and add whatever framework that snippet depends upon. Few people care about passing their JS through tools like JSLint, and many pages still have dozens of external JS references as well as numerous inline scripts. They just don't care. And that is hard to fix with standards because they don't care.
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
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 processing pig - with the addition of a few, well-defined constructs to HTML, with support from browsers, we could do a lot of what we want (or what people are doing) - without the overhead imposed by JavaScript To me, this seems like a very good thing. It seems like: - It's getting harder and harder to do simple things. Too many JavaScript frameworks and libraries. Too much complexity. Authoring should not require extensive programming skills. (Whatever happened to the read/write web?). - JavaScript seems to encourage poor programming style, or at least resource-intensive programming. It seems like 2/3 of the web pages I visit either freeze up, or just take incredibly long to load. Granted, that a lot of this is this stems from all the little click monitoring apps, and widgets, and who knows what else people put on their pages - and waiting for those various sites to respond - but it's the proliferation of more and more JavaScript that enables this. In HTML5 some functionality ordinarily provided by JavaScript that now can be done by HTML5, e.g. the details tag and progress tag, is still not universally supported by modern browsers requiring JavaScript fallback. I don't know why it takes the browsers so long to implement, but it does. The problem with JavaScript is that fewer and fewer web devs care. Rather than picking a framework (like jQuery) and sticking with it, they copypasta JS they find around the web (often in violation of the license) and add whatever framework that snippet depends upon. Few people care about passing their JS through tools like JSLint, and many pages still have dozens of external JS references as well as numerous inline scripts. They just don't care. And that is hard to fix with standards because they don't care.
Re: [whatwg] Thoughts on the nav element
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 outlines. A very common occurence is: [Untitled body] 1. Navigation 1. Page/article title Simply because the main nav (that is not tied to the page, but is global) HAS to come before the main element. I'm not sure how easy/hard it is to do some sort of automated test on the top X sites, to see what the outlines are, which elements are used and how we can propose better solutions, but that would be immensly helpful. Cheers, Reinier Kaper. On 27 March 2015 at 22:42, Andrea Rendine master.skywalker...@gmail.com wrote: 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 section? I think not. A first point is what Reinier underlined. With a structure as follows: [header with no heading elements] [navigation] [main with its own heading elements] an author would end up with an ugly and impractical (as stated by Reinier himself) structure: an untitled body, a navigation, and a main content presenting a heading, which is no longer the page content title as it was logically intended. Some authors (I'm among them) prefer different structures with one title for the page and one for main content, but defining main element as *not* sectioning allows a more agile structure... actually made non viable by a sectioning nav placed before main (and note that this is both a layout choice AND one dictated by logic, as site navigation is not to be considered part of the main content). On the other hand, consider a long navigation element enclosed in an aside. The spec suggests it can group a series of nav elements, but even a single nav list qualifies as content tangentially connected to the page topic. But aside is sectioning content too, and when using a single nav in aside, it forces an unnecessary further nesting [body] [aside] [nav] also forcing authors to put different titles when they want to avoid the poor default choice of Untitled xxx element. Having a strong semantic doesn't necessarily mean defining a section for the document, as emerged for main element too. I previously suggested that main itself could become a sectioner, but I have to retract because this solution is highly impractical... yes, as well as sectioning nav. This element is not even logically suitable to define anything - it just helps users retrieving navigational structures. Then, if authors need to *also* use it as a sectioner, nobody can stop them from defining it as a section, either implicitly (through a heading element) or explicitly (wrapping it in a strongly sectioning elements such as aside).
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
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, well-defined constructs to HTML, with support from browsers, we could do a lot of what we want (or what people are doing) - without the overhead imposed by JavaScript To me, this seems like a very good thing. It seems like: - It's getting harder and harder to do simple things. Too many JavaScript frameworks and libraries. Too much complexity. Authoring should not require extensive programming skills. (Whatever happened to the read/write web?). - JavaScript seems to encourage poor programming style, or at least resource-intensive programming. It seems like 2/3 of the web pages I visit either freeze up, or just take incredibly long to load. Granted, that a lot of this is this stems from all the little click monitoring apps, and widgets, and who knows what else people put on their pages - and waiting for those various sites to respond - but it's the proliferation of more and more JavaScript that enables this. (Which is not to say that some folks write well behaving pages, nor that JavaScript isn't useful - just that it seems to be leading to more and more problems). One would think that commercial developers would know better than to release pages that drive users away, but no. As to the specifics, it sounds like the proposal is to move some XML processing functions into the browser. To me, Xpath, XSLT and XQuery, maybe a basic XML database - all in a browser, instead of server-side - sounds like a viable alternative to JavaScript for a lot of applications. Implement first as a JavaScript library, as a test and transition path. Could be kind of cool. Might also end up being just as much of a processing pig as JavaScript. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: [whatwg] Thoughts on the nav element
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 section? I think not. A first point is what Reinier underlined. With a structure as follows: [header with no heading elements] [navigation] [main with its own heading elements] an author would end up with an ugly and impractical (as stated by Reinier himself) structure: an untitled body, a navigation, and a main content presenting a heading, which is no longer the page content title as it was logically intended. Some authors (I'm among them) prefer different structures with one title for the page and one for main content, but defining main element as *not* sectioning allows a more agile structure... actually made non viable by a sectioning nav placed before main (and note that this is both a layout choice AND one dictated by logic, as site navigation is not to be considered part of the main content). On the other hand, consider a long navigation element enclosed in an aside. The spec suggests it can group a series of nav elements, but even a single nav list qualifies as content tangentially connected to the page topic. But aside is sectioning content too, and when using a single nav in aside, it forces an unnecessary further nesting [body] [aside] [nav] also forcing authors to put different titles when they want to avoid the poor default choice of Untitled xxx element. Having a strong semantic doesn't necessarily mean defining a section for the document, as emerged for main element too. I previously suggested that main itself could become a sectioner, but I have to retract because this solution is highly impractical... yes, as well as sectioning nav. This element is not even logically suitable to define anything - it just helps users retrieving navigational structures. Then, if authors need to *also* use it as a sectioner, nobody can stop them from defining it as a section, either implicitly (through a heading element) or explicitly (wrapping it in a strongly sectioning elements such as aside).
