211–220 of 287 posts
Maybe it's just me, but I've never heard about the WHATWG before. And for everybody like me, that acronym stands for "Web Hypertext Application Technology Working Group".
Earlier quoted context omitted.
WHATWG is basically the browser vendors sidelining W3C to discuss what features HTML etc should have. The news today is that the W3C finally accepted that situation.
> WHATWG is basically the browser vendors sidelining W3C to discuss what features HTML etc should have. One way of looking at it is who has final say what ends up in the documents. That seems to be what you're discussing. In the W3C, that's the Director, Tim Berners-Lee. Except, as pointed out elsewhere in this thread, he has delegated all his decision-making powers to W3C staff. So ultimately it is the W3C CEO and t…
WHATWG fails to realize that they cannot represent the browser vendors left (Google and Google-financed Mozilla) having a desire for ever more webapp contamination, and web users and authors at the same time who want a stable content media format.
Also, I have to say your comment doesn't sound very promising wrt the future WHATWG/W3C relations being anounced.
I still maintain that the "living standard" is an oxymoron. It's a collaborative browser dev document. Don't get me wrong, that's great. However for everyone else an unversioned document, any part of which can change at any moment, is not what's usually thought of as a standard.
"Standard" = consensus definition of desired behaviour. "Living" = open to change. I don't see what is so oxymoronic about this? Just because a consensus has been reached doesn't mean that consensus must be immutable. Just because the process of standardisation in some technical domains has tended to use versioned documents doesn't mean that such an approach is fundamental to standardisation.
Earlier quoted context omitted.
We already have a native app but we are transitioning the majority of our core app to the web. Printing labels is one of the tricky parts that will be hard to transition. We are currently using an electron shell which makes maintenance easier but it still requires that end users install something which they might not have administrative rights to do. With WebUSB we expect that our entire app will be on the web and fu…
You have a working solution, and have decided to change to a platform that effectively doesn’t provide what you require to do business. Whoever makes the engineering decisions at your company is an idiot.
WebUSB is just one piece of tech that helps wrap up some of the edge cases.
Earlier quoted context omitted.
"Standard" = consensus definition of desired behaviour. "Living" = open to change. I don't see what is so oxymoronic about this? Just because a consensus has been reached doesn't mean that consensus must be immutable. Just because the process of standardisation in some technical domains has tended to use versioned documents doesn't mean that such an approach is fundamental to standardisation.
The point is that HTML is almost 30 years old, and based on SGML which is much older (even though ISO 8879 is officially "only" from 1986), where SGML is just a formalization of typesetting practices established in the 1960's and 1970's. Given the depth of usage of HTML in everyday life (laws, contracts in ecommerce, medical records, personal communication, education, etc., etc.), I think HTML deserves better than be…
That's good, because these aren't the reasons the HTML standard is changed, and to claim they are is absurd.
HTML may have had its origins in SGML, but it has long, long since grown past beyond those origins to become the web platform. Like any other non-dead software platform, it is undergoes a process of refinement and enhancement, not for reasons of "job security" or "Webkit dominance", but to provide additional functionality to allow more and better software to be build with of it, and to remain competitive with other software platforms.
You, and a large constituency of Hacker News commenters along with you, may utterly loathe the web platform. You may wish the web had evolved along entirely different lines, remaining a simple system for server hypertext documents. But the fact is, it didn't, and to act as if that the global development ecosystem that relies on the web platform doesn't exist is ridiculous.
Earlier quoted context omitted.
> I suspect at least part of the reason is to build a high barrier to entry and preserve the monopoly That is far too grand a motive. The reality is that the average web developer has a shelf life of about 5 years or is primarily focused elsewhere, such as Java or C#. That said consider the people who do this work with 100% focus. These people are typically not the same developers who are performing graduate level st…
You are already downvoted into oblivion and rightfully so, but I just wanted to add my perspective as a backend developer (and the one who did post-graduate level mathematical stuff at that) who now manages a team of back and front end developers and plays with front end development for toy projects. The sheer amount of complexity and required knowledge for front end development is simply baffling to me. These folks…
And none of that complexity is essential to the task, which by itself is a testament of the quality of the “web platform”.
Earlier quoted context omitted.
These are the same people who created XHTML, an ivory tower idea nobody was waiting for... who didn't support the most popular layout method at the time, tables, in their new styling language CSS. W3C became irrelevant because they kept thinking they could just tell the entire web what to do, that they'd make enormous technical investments to satisfy the W3C's latest fashions. I interacted with them once, over their…
> seamless iframe proposal. DOM v3 Document.load() https://www.w3.org/TR/DOM-Level-3-LS/load-save.html was the candidate for client side document loading long before most people even knew what W3C is
Earlier quoted context omitted.
I don't see this connection of XHTML and semweb XHTML continued the spirit of HTML 4 strict, getting rid of presentational elements and replacing them with 'sematic' ones. Eventually, you were also supposed to combine it with RDF to embed machine-readable metadata into your documents (cf https://www.w3.org/2003/03/rdf-in-xml.html and https://en.wikipedia.org/wiki/XHTML%2BRDFa ).
Also, XHTML 2 tried to push people to tags with defined semantics like ARTICLE, SECTION, MENU, etc. Most of the tags exist now in HTML5, but their semantics were neutered in the transition.
But it undoubtedly makes development harder. Web Developer 101: Section 1: This 20 page list of categories and their strict formal definitions.
Earlier quoted context omitted.
Did you miss the 5-10 years during which every CSS designer tortured themselves replicating tables with floats? Google 'pure css page footer' to see the wreckage. CSS tables took years to be supported, and even then, only brought back what people had been irrationally told to stay away from. It took another 5 years for flex box to become usable, adding something actually new. To this day, changing a site's entire des…
> Did you miss the 5-10 years during which every CSS designer tortured themselves replicating tables with floats? I never really understood why people had such difficulty with this. I was able to execute table-less layouts while still supporting IE5 on Mac. > To this day, changing a site's entire design without touching its markup is a mirage. That's only because HTML authoring is dead. No one writes HTML well these…
I lost a lot of hair trying to make a simple 3 column layout where the middle column would scale to the width of the window and could consist of multiple DIVs in a vertical row, all of the same width. AKA "baby's first blog" layout. Something that should have been one of the design cases for CSS.