Re: [whatwg] Supporting feature tests of untestable features
On 2015-04-01 06:57, Kyle Simpson wrote:
There are features being added to the DOM/web platform, or at least under
consideration, that do not have reasonable feature tests obvious/practical in
their design. I consider this a problem, because all features which authors
(especially those of libraries, like me) rely on should be able to be tested if
present, and fallback if not present.
Paul Irish did a round-up awhile back of so called undetectables here:
https://github.com/Modernizr/Modernizr/wiki/Undetectables
I don't want to get off topic in the weeds and/or invite bikeshedding about individual
hard to test features. So I just want to keep this discussion to a narrow
request:
Can we add something like a feature test API (whatever it's called) where certain
hard cases can be exposed as tests in some way?
The main motivation for starting this thread is the new `link rel=preload`
feature as described here: https://github.com/w3c/preload
Specifically, in this issue thread: https://github.com/w3c/preload/issues/7 I
bring up the need for that feature to be testable, and observe that as
currently designed, no such test is feasable. I believe that must be addressed,
and it was suggested that perhaps a more general solution could be devised if
we bring this to a wider discussion audience.
A featurecheck API? THat sort of makes sense.
I see two ways to do this.
One would be to call a function like (the fictional) featureversion()
and get back a version indicating that the browser support the ECMA
something standard as a bare minimum. But version checking is something
I try to avoid even when doing programming on Windows (and MicroSoft
advise against doing it).
So a better way might be:
featexist('function','eval')
featexist('document','link','rel','preload')
featexist('api','websocket')
Yeah the preload example does not look that pretty but hopefully you
know what I'm getting at here. Maybe featexist('html','link','preload')
instead?
On Windows programs I try to always dynamically load a library and then
I get a function pointer to a named function, if it fails then I know
the function does not exist in that dll and I can either fail gracefully
or provide alternative code to emulate the missing function.
It's thanks to this that on streaming audio player I made axctually
works on anything from Windows 2000 up to WIndows 8.1 and dynamically
makes use of new features in more recent Windows versions thanks to
being able to check if functions actually exists.
I use the same philosophy when doing Javascript and HTML5 coding.
With the featexist() above true is returned if present and false if not
present.
Now what to do if eval() does not exist as a pre-defined function but a
user defined eval() function exists instead for some reason.
My suggestion is that featexist() should return false in that case as it
is not a function provided by the browser/client.
Now obviously a|if (typeof featexist == 'function')| would have to be
done before calling featexist() and there is no way to get around that.
Another suggestion is that if a feature is disabled (by the user, the
admin or the browser/client for some reason) ten featexist() should
behave as if that feature does not existis not supported.
In other words featexist() could be a simple way to ask the browser if
is this available? can I use this right now?
--
Roger Hågensen, Freelancer, http://skuldwyrm.no/
Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen
On 2015-03-31 23:17, Felix Miata wrote: Roger Hågensen composed on 2015-03-31 21:09 (UTC+0200): ... For Mozilla browsers, you can go to about:config and set media.autoplay.enabled to “falseâ€�. Also, the NoScript browser extension can make media click-to-play by default. I hardly think a lot of users want to follow directions like that. As a programmer/content designer it would make more sense to do so using either attributes or javascript instead of bothering the user. Turning off autoplay is a one time thing, not a big deal like the constant disrespect of sites disregarding instead of embracing user needs. ... I have a hard time seeing rationality in any option other than click-to-play. *My* PC is a tool. *I* should be the one to decide if and when to play, and if or when to stop or pause. What are you suggesting exactly? That all iframes should be click to show? Are you talking about iframe visibility and autopause or autounload? If you are veering off topic then if possible please start a new thread (new subject) in that case. I'll assume you are talking about autopause for a video tag. As a user you open another tab, the video pauses at once (since the autopause attribute is set) since it's no longer visible. Now if you go back to it and click play and then tab away again then you have manually overridden the autopause. There might also be a autopause option on the video UI someplace. My suggestion was for a autopause for iframes, I only noted that it might be of use to video and audio tags as well but I did not really outline how hey should behave as this topic is about iframes rather than video and audio. Starting a new thread to discuss autopause and autounload or video and audio is preferred as that will require more UI discussion than iframes (which has no UI). -- Roger Hågensen, Freelancer, http://skuldwyrm.no/
Re: [whatwg] Supporting feature tests of untestable features
We had it but browser cendors abandoned its proper behavior [for some
historical reason unbeknownst to me]
DOMImplementation.hasFeature (document.hasFeature):
http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-5CED94D7
and
Node.isSupported:
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Level-2-Core-Node-supports
We are running into the exact same issues with the HTML Clipboard API being
unreliably detectable. Even more troubling, this is especially true because
it is already partially supported (paste events) in some browsers (e.g.
Chrome), not at all supported in others, and fully supported in none.
Sincerely,
James M. Greene
On Apr 1, 2015 3:36 AM, Roger Hågensen rh_wha...@skuldwyrm.no wrote:
On 2015-04-01 06:57, Kyle Simpson wrote:
There are features being added to the DOM/web platform, or at least under
consideration, that do not have reasonable feature tests obvious/practical
in their design. I consider this a problem, because all features which
authors (especially those of libraries, like me) rely on should be able to
be tested if present, and fallback if not present.
Paul Irish did a round-up awhile back of so called undetectables here:
https://github.com/Modernizr/Modernizr/wiki/Undetectables
I don't want to get off topic in the weeds and/or invite bikeshedding
about individual hard to test features. So I just want to keep this
discussion to a narrow request:
Can we add something like a feature test API (whatever it's called)
where certain hard cases can be exposed as tests in some way?
The main motivation for starting this thread is the new `link
rel=preload` feature as described here: https://github.com/w3c/preload
Specifically, in this issue thread: https://github.com/w3c/
preload/issues/7 I bring up the need for that feature to be testable,
and observe that as currently designed, no such test is feasable. I believe
that must be addressed, and it was suggested that perhaps a more general
solution could be devised if we bring this to a wider discussion audience.
A featurecheck API? THat sort of makes sense.
I see two ways to do this.
One would be to call a function like (the fictional) featureversion()
and get back a version indicating that the browser support the ECMA
something standard as a bare minimum. But version checking is something I
try to avoid even when doing programming on Windows (and MicroSoft advise
against doing it).
So a better way might be:
featexist('function','eval')
featexist('document','link','rel','preload')
featexist('api','websocket')
Yeah the preload example does not look that pretty but hopefully you know
what I'm getting at here. Maybe featexist('html','link','preload')
instead?
On Windows programs I try to always dynamically load a library and then I
get a function pointer to a named function, if it fails then I know the
function does not exist in that dll and I can either fail gracefully or
provide alternative code to emulate the missing function.
It's thanks to this that on streaming audio player I made axctually works
on anything from Windows 2000 up to WIndows 8.1 and dynamically makes use
of new features in more recent Windows versions thanks to being able to
check if functions actually exists.
I use the same philosophy when doing Javascript and HTML5 coding.
With the featexist() above true is returned if present and false if not
present.
Now what to do if eval() does not exist as a pre-defined function but a
user defined eval() function exists instead for some reason.
My suggestion is that featexist() should return false in that case as it
is not a function provided by the browser/client.
Now obviously a|if (typeof featexist == 'function')| would have to be
done before calling featexist() and there is no way to get around that.
Another suggestion is that if a feature is disabled (by the user, the
admin or the browser/client for some reason) ten featexist() should behave
as if that feature does not existis not supported.
In other words featexist() could be a simple way to ask the browser if
is this available? can I use this right now?
--
Roger Hågensen, Freelancer, http://skuldwyrm.no/
Re: [whatwg] Supporting feature tests of untestable features
On 4/1/15 8:27 AM, James M. Greene wrote: We had it but browser cendors abandoned its proper behavior [for some historical reason unbeknownst to me] The support signal (the hasFeature() implementation) was not in any way coupled with the actual implementation. So you would have cases in which hasFeature() claimed false even though the browser supported the feature, cases in which hasFeature() claimed true even though the browser didn't support the feature, and cases in which the browser had somewhat rudimentary support for the feature but hasFeature() claimed true because of various market pressures. This was especially driven by the coarse nature of the features involved -- you could at best ask questions like is this spec supported?, not is this particular piece of functionality supported?. That works OK for small targeted specs, but the W3C wasn't so much in the business of doing those. The upshot was that in any sort of interesting case hasFeature was useless at best and misleading at worst. We are running into the exact same issues with the HTML Clipboard API being unreliably detectable. Even more troubling, this is especially true because it is already partially supported (paste events) in some browsers (e.g. Chrome), not at all supported in others, and fully supported in none. So let's consider this case. How would a hasFeature deal with this situation? At what point would you expect it to start returning true for the clipboard API? -Boris P.S. Looking over the clipboard API, it seems like it really has the following bits: 1) The various before* events, which would be detectable if the spec added the corresponding onbefore* attributes to someplace, and 2) The copy/paste/etc events, which could likewise be detectable with on* attributes. Am I missing something else that is not detectable for fundamental reasons?
Re: [whatwg] Supporting feature tests of untestable features
P.S. Looking over the clipboard API, it seems like it really has the following bits: 1) The various before* events, which would be detectable if the spec added the corresponding onbefore* attributes to someplace, and 2) The copy/paste/etc events, which could likewise be detectable with on* attributes. Am I missing something else that is not detectable for fundamental reasons? Not to side-track this generalized conversation too much but it may actually be useful to detail the state of Clipboard API detection here based on current practices and APIs (which is completely hopeless): *Event-based detection:* The onbeforecopy, onbeforecut, onbeforepaste, oncopy, oncut, and onpaste events have all existed in IE, Safari, and Chrome (and now modern Opera, I'd imagine) for quite some time, related to standard user actions for copy/cut/paste (and more importantly for ContentEditable purposes, IIRC). So this approach would return false positives for at least every modern major browser other than Firefox (if not Firefox, too). *Method-based detection:* Firefox, for example, implements `clipboardData.setData()`/`clipboardData.getData()` and also implements the `ClipboardEvent` constructor, does not actually modify the user's clipboard on `clipboard.setData()`. Additionally, to even get access to `clipboardData`, you must be able to synthetically execute one of these commands (e.g. copy). So this approach isn't great, and will return false positives for Firefox anyway. *Command-based detection:* Since the actual actions like copy, etc. will be triggered via ye olde query commands (i.e. `document.execCommand`), another proper approach for detection would be using the `document.queryCommandSupported` and `document.queryCommandEnabled` methods to check for support. However, those methods work inconsistently cross-browser, some throw Errors instead of returning `false`, etc. Beside all that, the copy, cut, and paste query commands have all previously existed for ContentEditable purposes. So this approach is flawed, unreliable, and will return false positives. *Implementation-based detection:* As previously discussed in this thread, `document.implementation.hasFeature` and/or `Node.isSupported` could have been another idea for feature detection but has already been bastardized to the point of no return. So this approach, if implemented, would almost always return false positives (e.g. Firefox, if not all other browsers, returns `true` for everything). As far as checking on full implementations, it would be nice if specs followed some reliable versioning pattern like SemVer that we could use to verify the correct level of support. Even at that point, though: should such an approach only check against W3C specs or also WHATWG specs? Additionally, as you mentioned, it would be much better if we could create some API which would offer the ability to check for partial implementations (features/sub-features) vs. full spec implementations as well. For example, Chrome has implemented the paste feature of the Clipboard API nearly completely but has NOT implemented the copy or cut features. Sincerely, James Greene On Wed, Apr 1, 2015 at 8:07 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/1/15 8:27 AM, James M. Greene wrote: We had it but browser cendors abandoned its proper behavior [for some historical reason unbeknownst to me] The support signal (the hasFeature() implementation) was not in any way coupled with the actual implementation. So you would have cases in which hasFeature() claimed false even though the browser supported the feature, cases in which hasFeature() claimed true even though the browser didn't support the feature, and cases in which the browser had somewhat rudimentary support for the feature but hasFeature() claimed true because of various market pressures. This was especially driven by the coarse nature of the features involved -- you could at best ask questions like is this spec supported?, not is this particular piece of functionality supported?. That works OK for small targeted specs, but the W3C wasn't so much in the business of doing those. The upshot was that in any sort of interesting case hasFeature was useless at best and misleading at worst. We are running into the exact same issues with the HTML Clipboard API being unreliably detectable. Even more troubling, this is especially true because it is already partially supported (paste events) in some browsers (e.g. Chrome), not at all supported in others, and fully supported in none. So let's consider this case. How would a hasFeature deal with this situation? At what point would you expect it to start returning true for the clipboard API? -Boris P.S. Looking over the clipboard API, it seems like it really has the following bits: 1) The various before* events, which would be detectable if the spec added the corresponding onbefore* attributes to someplace, and 2) The
Re: [whatwg] Supporting feature tests of untestable features
P.S. If you want to get involved, here is a link to the archive of the most recent email thread about feature detection for the Clipboard API: https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0592.html Sincerely, James Greene On Wed, Apr 1, 2015 at 9:04 AM, James M. Greene james.m.gre...@gmail.com wrote: P.S. Looking over the clipboard API, it seems like it really has the following bits: 1) The various before* events, which would be detectable if the spec added the corresponding onbefore* attributes to someplace, and 2) The copy/paste/etc events, which could likewise be detectable with on* attributes. Am I missing something else that is not detectable for fundamental reasons? Not to side-track this generalized conversation too much but it may actually be useful to detail the state of Clipboard API detection here based on current practices and APIs (which is completely hopeless): *Event-based detection:* The onbeforecopy, onbeforecut, onbeforepaste, oncopy, oncut, and onpaste events have all existed in IE, Safari, and Chrome (and now modern Opera, I'd imagine) for quite some time, related to standard user actions for copy/cut/paste (and more importantly for ContentEditable purposes, IIRC). So this approach would return false positives for at least every modern major browser other than Firefox (if not Firefox, too). *Method-based detection:* Firefox, for example, implements `clipboardData.setData()`/`clipboardData.getData()` and also implements the `ClipboardEvent` constructor, does not actually modify the user's clipboard on `clipboard.setData()`. Additionally, to even get access to `clipboardData`, you must be able to synthetically execute one of these commands (e.g. copy). So this approach isn't great, and will return false positives for Firefox anyway. *Command-based detection:* Since the actual actions like copy, etc. will be triggered via ye olde query commands (i.e. `document.execCommand`), another proper approach for detection would be using the `document.queryCommandSupported` and `document.queryCommandEnabled` methods to check for support. However, those methods work inconsistently cross-browser, some throw Errors instead of returning `false`, etc. Beside all that, the copy, cut, and paste query commands have all previously existed for ContentEditable purposes. So this approach is flawed, unreliable, and will return false positives. *Implementation-based detection:* As previously discussed in this thread, `document.implementation.hasFeature` and/or `Node.isSupported` could have been another idea for feature detection but has already been bastardized to the point of no return. So this approach, if implemented, would almost always return false positives (e.g. Firefox, if not all other browsers, returns `true` for everything). As far as checking on full implementations, it would be nice if specs followed some reliable versioning pattern like SemVer that we could use to verify the correct level of support. Even at that point, though: should such an approach only check against W3C specs or also WHATWG specs? Additionally, as you mentioned, it would be much better if we could create some API which would offer the ability to check for partial implementations (features/sub-features) vs. full spec implementations as well. For example, Chrome has implemented the paste feature of the Clipboard API nearly completely but has NOT implemented the copy or cut features. Sincerely, James Greene On Wed, Apr 1, 2015 at 8:07 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/1/15 8:27 AM, James M. Greene wrote: We had it but browser cendors abandoned its proper behavior [for some historical reason unbeknownst to me] The support signal (the hasFeature() implementation) was not in any way coupled with the actual implementation. So you would have cases in which hasFeature() claimed false even though the browser supported the feature, cases in which hasFeature() claimed true even though the browser didn't support the feature, and cases in which the browser had somewhat rudimentary support for the feature but hasFeature() claimed true because of various market pressures. This was especially driven by the coarse nature of the features involved -- you could at best ask questions like is this spec supported?, not is this particular piece of functionality supported?. That works OK for small targeted specs, but the W3C wasn't so much in the business of doing those. The upshot was that in any sort of interesting case hasFeature was useless at best and misleading at worst. We are running into the exact same issues with the HTML Clipboard API being unreliably detectable. Even more troubling, this is especially true because it is already partially supported (paste events) in some browsers (e.g. Chrome), not at all supported in others, and fully supported in none. So let's consider this case.
Re: [whatwg] MetaExtension and Dublin Core revision
Mr. Hickson, please let me know if further details are needed, or otherwise if change proposal will be accepted, at least partially. The more those properties remain there, the more authors can read them and use them incorrectly IMHO. Yours respectfully, Andrea 2015-03-26 18:19 GMT+01:00 Andrea Rendine master.skywalker...@gmail.com: A note about DC.xxx properties. According to the spec, the properties marked in my mail can be used as DC-prefixed, though in the wild the DCTERMS prefix is largely preferred. If these properties were to be used, it should be specified that the correct namespace declaration is *not* link rel=schema.dc href= http://purl.org/dc/elements/1.1/;, but something like link rel=schema.dc href=http://purl.org/dc/terms/;. DC prefix is used with both namespaces for legacy compatibility, but the prevalence of DCTERMS over DC is about 100 to 1. All this does not apply to dc.date.issued, which simply does not exist (the correct property name is dc.issued). You can find all sources for those properties at http://dublincore.org/documents/2012/06/14/dcmi-terms/ Cheers, Andrea Rendine
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mar 31, 2015, at 12:43 PM, Joshua Cranmer pidgeo...@verizon.net wrote: On 3/30/2015 10:02 PM, Bobby Mozumder wrote: One thing I’m interested in is to see more technical discussions around this idea. Like, very specific issues that show a design or concept flaw. It’s only been about 10 days since I proposed this and I haven’t received much in that area. (I did change one thing to split MREF from HREF based on feedback about people wanting backwards compatibility.) Technical discussion is the last step of the process. The reason why people haven't provided technical feedback is because you have failed to motivate your proposal. I gave a limited one-page idea for now, so design faults should be obvious. This will take years, but right now it’s looking like there aren’t fundamental problems with the proposal. Most of the unnecessary arguments against it boil down to people just stuck in their comfort-zone, and those people aren’t the target audience for this proposal anyways. Javascript people are going to be happy with their existing selection of MVC frameworks, so why would they want anything new like this? The mistake Javascript developers are making is that they make the assumption that everybody else is a Javascript developer. Instead, I’m mostly getting a lot of “I’m scared!” or “Everyone should get a PhD in Javascript like I did!” which obviously isn’t going to happen. So, if there are technical faults with the proposal here, definitely list them. (or preferably in the Github, where I can keep track of issues directly) Attacking your detractors with ad hominems is a great way to get yourself ignored. People aren't saying those things--they're questioning the utility of your proposal in the first place. You take it for granted that HTML needs a complex, SQL-based MVC framework. You take it for granted that JS is the devil and should be avoided. You appear to take it for granted that using JS frameworks is a problem that needs to be solved. These views are not commonly held on this mailing list, and you're completely ignoring the feedback which is, in effect, questioning these assumptions. Not ad hominem. I’ve literally had developers tell me everyone should learn Javascript. Example: https://twitter.com/yoavweiss/status/582490158496419840 That's obviously a horrible idea. Why would anyone encourage millions of other people to do more work? Everyone’s time is limited. Why should a fashion-blogger spend time to learn JS to get a responsive high-speed site? They have other things to worry about, like next season’s collections. The best experience should be on by default, and you need a built-in MVC framework in HTML for that to happen. We need to be able to advance the web without going through Javascript. It’s a mistake to assume that JS is a fundamental part of the web. The web is optimized for hypertext document processing, and most people use it to read content online. This proposal fixes a remaining issue with that. Serious question: why? What benefit does it bring? That JS is bad is not a self-evident proposition. You’re asking people to learn Javascript, an MVC framework, and its associated templating system, to fix a basic user experience problem with the web. I was talking with a Tumblr power user a couple of days ago about this and she confirmed that all Tumblr kids pretty much know the basics of HTML, somewhat fewer people know CSS, and nobody knows Javascript. Tumblr maintains about 200 million sites. Given all that, what’s your proposal to put forth an app-like high-speed responsive web experience without using Javascript? Because any plan that includes “Need to know Javascript” will fail. You’ll find that the kind of proposal I’m putting out there is the only viable solution. -bobby --- Bobby Mozumder Editor-in-Chief FutureClaw Magazine mozum...@futureclaw.com mailto:mozum...@futureclaw.com +1-240-745-5287 www.futureclaw.com http://www.futureclaw.com/ twitter.com/futureclaw https://www.twitter.com/futureclaw www.linkedin.com/in/mozumder http://www.linkedin.com/in/mozumder
Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen
On Mon, Mar 30, 2015 at 03:47:26PM -0700, Seth Fowler wrote: I think we should modify the Page Visibility spec to let UA’s take actual visibility of iframes into account when deciding if an iframe is hidden. Right now, the visibility of an iframe is the same as that of the top level browsing context it’s embedded in. Here are the details: http://www.w3.org/TR/page-visibility/ This design doesn’t do much for iframes which may be doing significant work, though. The most obvious example is HTML5 ads. These ads may be performing significant work - computation, network IO, rendering, etc. Some or all of that work is often unnecessary when the ad is outside the viewport. Having an API that would allow those ads to throttle back their work when they’re not visible could have significant positive effects on performance and battery life. I am concerned that if an iframe is on its honor to use the API, the API will have a very small impact, when mandatory resource arbitration seems to be needed. Responsibility for good performance and battery life on my laptop should belong to my UA, not to the web developer. I cannot take for granted the good will of the web developer, and even developers with good intentions may make a mistake or cut corners. It seems to me that the UA should divvy up resources among iframes based on the availability of an *audience* to each one. Invisible pages, occluded iframes, iframes that have scrolled out of the viewport, and so on, definitely shouldn't get a prime share unless the user has made an explicit grant. Give the bulk of the resources to what you could conceivably be looking at. Do you see what I'm getting at? Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen
On Apr 1, 2015, at 10:35 PM, David Young dyo...@pobox.com wrote: I cannot take for granted the good will of the web developer, and even developers with good intentions may make a mistake or cut corners. Trust me, you’re preaching to the choir on that! It seems to me that the UA should divvy up resources among iframes based on the availability of an *audience* to each one. Invisible pages, occluded iframes, iframes that have scrolled out of the viewport, and so on, definitely shouldn't get a prime share unless the user has made an explicit grant. Give the bulk of the resources to what you could conceivably be looking at. Do you see what I'm getting at? Absolutely. I think all of the UAs have implemented features like that, and are working on more. But making iframes aware that they should throttle themselves is still helpful, because well-behaved iframes can take drastic action to reduce their performance and energy impact - even totally stopping all their processing. UAs always have to worry about breaking existing web content, and it’s often hard to take such drastic action automatically for that reason. I think we’ll get the best results if we take both approaches simultaneously. - Seth
