Roger Hågensen writes:
> On 2015-04-09 11:43, Nils Dagsson Moskopp wrote:
>> Roger Hågensen writes:
>>
>>> Myself I have to confess that I tend to use caniuse a lot myself. I use
>>> it to check how far back a feature goes in regards to browser versions
>>> and try to decide where you cut the line In other words I'll end up
>>> looking at a featyre and thinking that "OK! IE10 supports this feature,
>>> IE9 does not, so minimum IE target is then IE10).
>>>
>> Have you tried progressive enhancement instead of graceful degradation?
>> I usually build a simple HTML version of a page first, check that it
>> works using curl or elinks, then enhance it via polyfills and other
>
> I have, but found that relying on polyfills is no different than relying
> on a work around or a 3td party framework.
> It easily ads to code bloat, and I'm now moving more and more towards
> static pages with JS and CSS specific to a page are embed in the page as
> that support fast static delivery.
I believe the benefit of progressive enhancements is exactly that – fast
static delivery and resilience to errors. Maybe I was wrong to point to
polyfills as a method of providing future-proof web pages … ?
> I don't mind waiting a few months or a year for a feature to be added
> and available among all major modern browsers. Once a feature is
> available like that then I make use of it (if I have use for it) to
> support the effort of it being added.
To “support the effort” ? Could you elaborate on that motivation?
> This does mean I end up going back to old code and stripping
> out/replacing my own code that do similar things.
> Or to enhance/speed up or simplify the way my old code works.
> I don't mind this, it's progress and it gradually improves my code as
> the browsers evolve.
> If ten years from now my old pages no longer look/work as intended then
> that is on me or whomever do maintenance them.
> If they are important enough then the pages will migrate to newer
> standards/features over time naturally.
My personal goal for a web page is that it will always work – no
maintenance needed. Granted, there are parties that think that no
Software should be in a finished state (such as those who wish for
deprecation of plain text HTTP or removal of XSLT from user agents) –
but I hope newer browsers will show ancient pages in the future as well
as they do now!
> I do miss HTML versioning to some extent though, being able to target a
> 5.0 or 5.1 minimum (or lowest common denominator) would be nice.
> Though this can possibly be missused.
>
> I have seen another approach though to versioning that may be worth
> contemplating though...
>
> Using Javascript one call a function and the browser if this version is
> supported. Example:
> if (version_supported('javascript',1,2))
>
> or
> if (version_supported('css',3,0))
>
> or
> if (version_supported('html',5,0))
>
>
> The browser could then simply return true or false.
> True would mean that all features in the speced version is supported.
> False would mean that they are not.
Fun fact: Usually no browser supports all features in the spec.
Additionally, at least the HTML 5 spec tends to mutate a bit.
> I'm using something similar for a desktop programming API I'm working
> on, the application simply asks if the library support this version
> (number hardcoded at the time the program was compiled) and the library
> answers true or false.
> This avoids programmers from accidentally parsing a version number
> wrong, the library is coded to do it correctly instead.
Parsing version numbers sets you up for failures as well, unless you are
doing upgrades and want to know if the current version or a newer one is
installed right now.
> There would still be a small problem where a browser may support for
> example all of CSS 2 but only parts of CSS3.
>
> But in that case it would return True for CSS 2.0 but false for CSS 3.0
> So "some" feature detection would still be needed to detect that.
Feature detection is always needed. Which browser does all of CSS 2? I
have never seen a user agent that can do aural style sheets – and Chrome
implemented the clip() property in an unexpected way last time I looked.
> But being able to ask the browser a general question if it will be able
> to handle a page that targets CSS 3, HTML5, JS 1.2 would simplify things
> a lot.
It is easy to come up with a solution that is simple, obvious and wrong.
> If actual version numbers is an issue. Why not use years, like so:
>
> if (version_supported('javascript',2004))
>
> or
> if (version_supported('css',2009))
>
> or
> if (version_supported('html',2012))
>
> Essentially asking, "do you support the living spec from 2012 or later?".
What does that even mean? Did you mean to write “from 2012 or earlier” ?
> I think that using years may possibly be better than versions (and
> you'll never run out of year numbers nor need to start from 1.0 again).
> And if finer granularity is needed then mont
