Earlier quoted context omitted.
has never been in any HTML specification since time began.
And yet it can be supported just fine.
To nit-pick, no. You can emulate it, not support it, cause it doesn't exist anymore.
HTML 5.2 Recommendation
171–180 of 188 posts
Re: HTML 5.2 Recommendation
#172Earlier quoted context omitted.
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.
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…
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.
Re: HTML 5.2 Recommendation
#173Earlier quoted context omitted.
The former. The problem is just that you've learned what the latter means better than the former. I'm the opposite. Plus, the former is an absolute value where the latter is not, as far as I've been able to tell. I know that first span will always be 10pt font. I have no idea what "2" even means in this context.
Another commenter did you a favor and explained why using 10pt is worse than using 2: https://news.ycombinator.com/item?id=15927837
That may be true, but regardless of whether pt is a best practice, the point remains that it is still a unit. IMO that puts it ahead of the alternative example.
Re: HTML 5.2 Recommendation
#174Earlier quoted context omitted.
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…
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 y…
"C99 is substantially completely supported as of GCC 4.5 (with -std=c99 -pedantic-errors used; -fextended-identifiers also needed to enable extended identifiers before GCC 5), modulo bugs and floating-point issues (mainly but not entirely relating to optional C99 features from Annexes F and G)." [1]
Sounds fully supported to me, for all practical purposes.
"Default standard is now GNU11" [2]
What do you know that I don't?
Re: HTML 5.2 Recommendation
#175Earlier quoted context omitted.
I wouldn't mind some extra information you have on this. When I've spoken to folks at the browser vendors one-on-one, they've talked about following WHATWG, rather than the W3C standard, but usually that was in conversations that were critical of the W3C, so it was hard to tell how ubiquitous that position was.
I am having trouble finding the background information on this. Basically, the WHATWG took the W3C DOM and wildly changed some foundational concepts without a thorough understanding of what those decisions mean. Here is a very simplified description of this problem years after the fact: https://github.com/whatwg/dom/issues/102 It is important to understand the DOM wasn't created for HTML. The DOM, starting with DOM l…
This specific decision turned out to be mistaken, but W3C makes this type of mistake way more often and doesn't even always fix them. You can see in the record of this issue that the problem was eventually resolved. WHATWG Working Mode has also been updated since this change and would not allow this type of change to be made today without implementor support.
Regardless of issues like this, browsers track WHATWG DOM near exclusively. You can see devs from all of the major browser engines commenting in the issue you linked.
Re: HTML 5.2 Recommendation
#176Earlier quoted context omitted.
is no longer supported by browsers, but with a few css declarations it works just fine. Removing support for presentational markup does not mean a loss of information. Browsers will still render tags they don't recognize, and re-applying the styling of those tags is often trivial. (I mention because it's one of the more difficult, but not terribly so) As the web evolved, our needs changed. Do we still need the tag?
I think you're missing the OP's point though. It's true that you can just use some CSS to make up for the lost HTML feature, but than again you could also rewrite the HTML part. Forgive me if I'm wrong, but I'm fairly sure that what the OP is trying to say, is that there are plenty of great websites out there, which were developed a long time ago, and for which there is no maintainer to do any work on it. Thus having…
The "plenty of great websites" were developed long time ago. Having a degree of visual consistency of layout across different browsers was not possible then according to standards.
The content will not be lost. The tags will result in valid elements but the rendering may vary. This has always been a thing to be expected, since legacy elements (pre HTML5) never had uniform rendering and contained quirks.
Should the current/new standard have support for ambiguously rendered quirky elements? Is it even a standard then?
After HTML5 the end result will definitely be the same on most (if not all) layout engines. The standardization as a process requires non-conforming legacy to be dropped.
Re: HTML 5.2 Recommendation
#177Earlier quoted context omitted.
The HTML mode tag should put the browser into compatibility mode. This content should not be lost.
Mode tag? Compatibility mode?
This covers the situation. Quirks mode is a legacy-compatible mode for old pages. https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mod...
Re: HTML 5.2 Recommendation
#178Earlier quoted context omitted.
I think you're missing the OP's point though. It's true that you can just use some CSS to make up for the lost HTML feature, but than again you could also rewrite the HTML part. Forgive me if I'm wrong, but I'm fairly sure that what the OP is trying to say, is that there are plenty of great websites out there, which were developed a long time ago, and for which there is no maintainer to do any work on it. Thus having…
I may not have expressed myself clearly, but I understood what OP was saying. Never overnight and post, kids. I was thinking about something like Stylish or the user stylesheet I've been hearing about in Firefox (for their UI IIRC, but still). Inject some global css on older/missing doctypes, and it's probably less than 200 total declarations to handle every older tag. I'd imagine to be the hardest and/or longest, fo…
Not sure I'm getting you… An extension to view old pages? This is the worst idea I've heard in a long time. The web is awesome partly because it's backwards compatible.
Re: HTML 5.2 Recommendation
#179Earlier quoted context omitted.
I may not have expressed myself clearly, but I understood what OP was saying. Never overnight and post, kids. I was thinking about something like Stylish or the user stylesheet I've been hearing about in Firefox (for their UI IIRC, but still). Inject some global css on older/missing doctypes, and it's probably less than 200 total declarations to handle every older tag. I'd imagine to be the hardest and/or longest, fo…
Not sure I'm getting you… An extension to view old pages? This is the worst idea I've heard in a long time. The web is awesome partly because it's backwards compatible.
I'm not saying I want that, I'm saying it'd be super simple to do if things came to that.
My primary point is that presentational markup is not required to get value from all but the most meta of old pages.
Re: HTML 5.2 Recommendation
#180Earlier quoted context omitted.
I'm really afraid that this is preparing the final drop of browser support. (We've seen similar in http, where many of the http/1.1 (1997) features, like multipart-http, for-headers, etc. aren't supported by any client for years by now.) As for MS-Word and HTML: When I finished my thesis in the mid-1990s, I saved it both in the MS-Word version, I used to write it (MS Word 5 for Mac), and HTML (expecting future compat…
What do you mean by "browser support"? What functionality do you expect to go away that would prevent you from viewing an old HTML file in a modern browser?
E.g., drop of framesets. Many old documentations use them, as do most websites from the second half of the 1990s (so-called 2nd gen. websites). Without frames, the content can't displayed in context anymore and consistency of presentation is lost entirely.