191–200 of 287 posts
Earlier quoted context omitted.
AMP, WebUSB, WebBluetooth all indicate otherwise.
What are they doing to harm WebUSB and WebBluetooth?
Earlier quoted context omitted.
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…
>The sheer amount of complexity and required knowledge for front end development is simply baffling to me 99% of it is self-inflicted though. You didn't need react/redux/sagas/uber popular framework 7.5 to do your job, but you and your coworkers thought "This is the cool new toy that facebook made!!!! Let's use it!!!" When 90% of web sites are reinventing a wheel made in 1994, there's no reason to actually do most of…
Earlier quoted context omitted.
I never understood that either except, as you said, for the hobbyist's sake. A lot of XHTML was generated from XML and, if one is using XML, chances are programming is involved in the transformation to XHTML. But programming has strict rules itself and will also fail if not adhered to so I never understood the complaint of "draconian" error checking in XML/XHTML.
> But programming has strict rules itself and will also fail if not adhered to so I never understood the complaint of "draconian" error checking in XML/XHTML. In most cases, if your code has some syntax error, the author of the code sees the syntax error; in the web case, if your code has some syntax error, the user sees the syntax error. That's the dramatic difference. The other reality is unlike program code, there…
Good writers of markup will always check with those before they ship it. In the case of user supplied markup, that's still an issue today with HTML.
Earlier quoted context omitted.
You have to take the mindset that "giant bundles of JavaScript" aren't how we want to build the web but to begin to ship more and more of the web baked into browsers instead. And that even "static HTML" requires accessibility improvements and adaptations to new device types. For example, split screen phones, where you've a mobile device that starts at one size, but then can open up to a larger size. Tiny watch apps,…
> You have to take the mindset that "giant bundles of JavaScript" aren't how we want to build the web but to begin to ship more and more of the web baked into browsers instead. "giant bundles of JavaScript" weren't how we shipped the web before the HTML5 process began. The solution to "we're loading too much overengineered bloated redundant logic over HTTP" isn't "lets bundle all of that logic", it's "stop overengine…
https://github.com/whatwg/html/commits
Let’s see, right off the top we’ve inputmode attr which helps support different keyboards on plain input text controls, we’ve enterkeyhint which lets you pick from a list of options for the enter key on virtual keyboards - both of these changes improve the usability and accessibility of the keyboard on newer touch screen devices. Form-associated custom elements let you create your own HTML elements that can participate in forms (the goal of custom elements is to help you build your own custom LEGO pieces instead of relying on the basic blocks the HTML spec includes — one could think of this as an eventual replacement of JSX components with HTML-based ones), autocomplete=one-time-code (thanks, iOS!), more granular control over file downloads, updating the spec to match reality (what browsers actually implemented for compatibility vs what was written in advance), srcset for retina (which reminds me, lazy loading images as a simple img tag attribute), WeakMap/WeakSet to help reduce memory leaks from stale DOM node references, requestAnimationFrame and other enhancements to the page lifecycle, CSP headers and related HTML attribute changes, and well, the list doesn’t end. ;-) For accessibility there’s the inert attribute that prevents focus to child content which is great if you need more flexibility than the dialog element provides by default but don’t want to get into setting tabindex manually or controlling all focus with JS, etc.
Earlier quoted context omitted.
>The sheer amount of complexity and required knowledge for front end development is simply baffling to me 99% of it is self-inflicted though. You didn't need react/redux/sagas/uber popular framework 7.5 to do your job, but you and your coworkers thought "This is the cool new toy that facebook made!!!! Let's use it!!!" When 90% of web sites are reinventing a wheel made in 1994, there's no reason to actually do most of…
Bullshit. More and more front-end developers are building applications. These projects aren't in anyway equivalent to a 1994 website.
See the framework fallacy https://news.ycombinator.com/item?id=20014888
Earlier quoted context omitted.
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…
Stop being offended and have some objectivity. I am a front end developer and I am describing myself as much as anyone else.
Earlier quoted context omitted.
What are they doing to harm WebUSB and WebBluetooth?
They're not doing anything to "harm" them, they created both of them, and both specs basically include a caveat that says "this could be mis-used, but YOLO".
If you are making a web app (like my company does) that needs to print to a label printer how should we do that besides switching to a native app that all of our clients need to install and maintain? WebUSB gives us an option of doing it in a seamless and maintainable way.
Earlier quoted context omitted.
Sure. IMHO one solution might be to have a HTML standard specification that is stable, which can then be built on. Extensions can be proposed so long as they don't break the standard. This would allow new elements and attributes to be introduced before they are themselves fully stable, as they are now. Breaking changes would require bumping the spec to a new major version and should happen only rarely.
We have HTML standards that ar stable. 4.01 e.g. The problem is that no browser ever implemented all of it, and even implemented parts were done differently.
No browser will ever implement the current spec because it's shifting sand. A smaller but stabilised spec that can be extended is much better for everybody who isn't a major browser vendor.
Earlier quoted context omitted.
XHTML documents have exactly the same semantics as HTML. Neither is more semantically sound than the other. XHTML just defined a slightly different syntax which was XML compatible. This was useful if you were using XML tools, but it didn't affect semantics at all.
XHTML 2.0 was very different from HTML semantically. Some of its tags (ARTICLE, SECTION, MENU, etc) wound up smashed into HTML5 later and became semantically meaningless again, but XHTML 2.0 tried to be more semantically sound than HTML and is a large part of how W3C lost the war to HTML5, because semantics are hard and most of the browsers didn't care about semantics.