4 ms·

I wish WHATWG would properly version their work. I don't like the idea of a "living standard" because it leads to checking for individual functionality and feat

I wish WHATWG would properly version their work. I don't like the idea of a "living standard" because it leads to checking for individual functionality and feature detection, rather than being able to say, "This is fully HTML 5.x.x compliant." Regardless of the state of W3C, if I built an embedded renderer based on their specs, I could at least say, "this renderer is based on <http-ref> and link to the recommended spec version. Whereas if I did that with the living standard href, I'd be out of date any time they decided to rename an attribute.

geofft 9y ago
But that's the point - web authors are supposed to use feature detection instead of writing to a particular standard version. It turns out to be a better model for large interfaces. Yes, in theory, you can ask "Is this OS POSIX.1-2008-compliant or not." In practice, it takes a while to e fully POSIX.1-2008-compliant, and so you get autoconf, with its individual feature detections of specific function. Less clean, but way more practical. If you're writing an embedded renderer, you can always say "This is compliant with the standard as of 14 December 2017." If you're writing an embedded renderer that is being applied to the live web and not just to a fixed set of pages that are also embedded (e.g., you're shipping HTML documentation and a viewer, or a kiosk, or something), you will in fact be out-of-date when the living standard changes. There's no point in saying "I'm compatible with HTML 5.2.0" because the live web isn't targeting 5.2 any more. So you can either acknowledge that, or figure out how to get software updates.
- andrewmcwatters 9y ago
  Good point, thanks. I suppose that's just the nature of it.
- colanderman 9y ago
  How does one perform feature detection in a static HTML page? As far as I can tell the only way to author a compatible web page these days is by checking every damn feature of HTML you use against some humongous table like Can I Use? before assuming your audiences' browsers support it. Compare to versioned specs, where I need simply determine the minimum spec version supported by my target audience (and any exceptions to the spec) and code against that spec. There is some utility in naming sets of well-supported features...
  - tptacek 9y ago
    By using conditional includes and fallback CSS.
    - colanderman 9y ago
      Unless "conditional includes" are some new feature of HTML5 that my Google-fu isn't turning up, that kind of negates the whole "static HTML" thing. Bootstrapping a web page through JavaScript polyfills is like autoconf all over again.
      - tptacek 9y ago
        The problem with autoconf is that it detects every conceivable Unix featuring going all the way back to the 1980s, not that feature detection is itself that problematic.
        colanderman 9y ago
        Right, hence my assertion that well-known names of feature sets are useful. "HTML 5.2" is useful in the same way that "C99" was, because eventually there is a day I can just assume everything in "HTML 5.2" is present in all my targets. If I don't have such a name, if I'm forever at "HTML 5", I'm forced into the "autoconf" scenario of using feature detection forever for everything not in the base specification. (That the W3C is apparently incompetent at associating feature sets with names is a separate issue.)
        andrewmcwatters 9y ago
        Right on about the C99 analogy, thanks. That's my concern.
        jcranmer 9y ago
        It's funny that you use C99 as an analogy. Please list all the compilers you support that support C99. I'll give you a hint--MSVC, Clang, and gcc all don't support C99 fully, and possibly never intend to. It's not just an idle "oh, no one cares about those features; they support it for all intents and purposes": gcc kept its default standard at C89 in part because it didn't support C99 fully. What you're doing when you say that you assume C99 compliance is you're thinking of the features from C99 that you want to use and relying on that. Admittedly, the generally-unsupported features are very niche. But that means that you potentially have a dozen different ideas of what "we support C99" actually means, and that's before you start asking how reliable an implementation needs to be before it meets the definition of "support." Declaring support for versioned standards is often more problematic than helpful (versioned implementations is a different story). The real problem with autoconf is that no one removes the unnecessary feature checks and no one audits it to see what's still necessary for the platforms that people intend to support.
foolip 9y ago
I know it's not quite what you're asking for, but each commit gets its own URL that you can use if you want to refer to a bit of text and know the link won't break: https://html.spec.whatwg.org/commit-snapshots/0184feb8b468f2069741e700a935fc5e2785ede8 https://html.spec.whatwg.org/commit-snapshots/0184feb8b468f2...

geofft 9y ago

But that's the point - web authors are supposed to use feature detection instead of writing to a particular standard version. It turns out to be a better model for large interfaces. Yes, in theory, you can ask "Is this OS POSIX.1-2008-compliant or not." In practice, it takes a while to e fully POSIX.1-2008-compliant, and so you get autoconf, with its individual feature detections of specific function. Less clean, but way more practical. If you're writing an embedded renderer, you can always say "This is compliant with the standard as of 14 December 2017." If you're writing an embedded renderer that is being applied to the live web and not just to a fixed set of pages that are also embedded (e.g., you're shipping HTML documentation and a viewer, or a kiosk, or something), you will in fact be out-of-date when the living standard changes. There's no point in saying "I'm compatible with HTML 5.2.0" because the live web isn't targeting 5.2 any more. So you can either acknowledge that, or figure out how to get software updates.

andrewmcwatters 9y ago
Good point, thanks. I suppose that's just the nature of it.
colanderman 9y ago
How does one perform feature detection in a static HTML page? As far as I can tell the only way to author a compatible web page these days is by checking every damn feature of HTML you use against some humongous table like Can I Use? before assuming your audiences' browsers support it. Compare to versioned specs, where I need simply determine the minimum spec version supported by my target audience (and any exceptions to the spec) and code against that spec. There is some utility in naming sets of well-supported features...
- tptacek 9y ago
  By using conditional includes and fallback CSS.
  - colanderman 9y ago
    Unless "conditional includes" are some new feature of HTML5 that my Google-fu isn't turning up, that kind of negates the whole "static HTML" thing. Bootstrapping a web page through JavaScript polyfills is like autoconf all over again.
    - tptacek 9y ago
      The problem with autoconf is that it detects every conceivable Unix featuring going all the way back to the 1980s, not that feature detection is itself that problematic.
      - colanderman 9y ago
        Right, hence my assertion that well-known names of feature sets are useful. "HTML 5.2" is useful in the same way that "C99" was, because eventually there is a day I can just assume everything in "HTML 5.2" is present in all my targets. If I don't have such a name, if I'm forever at "HTML 5", I'm forced into the "autoconf" scenario of using feature detection forever for everything not in the base specification. (That the W3C is apparently incompetent at associating feature sets with names is a separate issue.)
        andrewmcwatters 9y ago
        Right on about the C99 analogy, thanks. That's my concern.
        jcranmer 9y ago
        It's funny that you use C99 as an analogy. Please list all the compilers you support that support C99. I'll give you a hint--MSVC, Clang, and gcc all don't support C99 fully, and possibly never intend to. It's not just an idle "oh, no one cares about those features; they support it for all intents and purposes": gcc kept its default standard at C89 in part because it didn't support C99 fully. What you're doing when you say that you assume C99 compliance is you're thinking of the features from C99 that you want to use and relying on that. Admittedly, the generally-unsupported features are very niche. But that means that you potentially have a dozen different ideas of what "we support C99" actually means, and that's before you start asking how reliable an implementation needs to be before it meets the definition of "support." Declaring support for versioned standards is often more problematic than helpful (versioned implementations is a different story). The real problem with autoconf is that no one removes the unnecessary feature checks and no one audits it to see what's still necessary for the platforms that people intend to support.

foolip 9y ago

I know it's not quite what you're asking for, but each commit gets its own URL that you can use if you want to refer to a bit of text and know the link won't break: https://html.spec.whatwg.org/commit-snapshots/0184feb8b468f2069741e700a935fc5e2785ede8 https://html.spec.whatwg.org/commit-snapshots/0184feb8b468f2...