- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Thu, 24 Nov 2016 10:07:35 +0100
- To: public-html@w3.org
On 24/11/2016 09:50, Ian Yang wrote: > Personally, I think Domenic's reason is flawed, too. An arguably flawed > feature in HTML is widely used so we should not deprecate it and improve > HTML? I don't understand that logic. Once a certain markup pattern/feature is so widely deployed, for such a long time, you hit a few snags when trying to retrospectively change it: - the vast number of content out in the wild that uses the "old" (current) structure. How should user agents handle this if the structure was changed? Should they include handling for both "legacy" and "new" structures? How would they switch between them? (we've had this years ago with the dreaded quirks mode vs standards mode, and it's not pretty) - the number of user agents in the wild that consume HTML - not just the latest versions of the most common browsers (which can arguably be changed easily enough to handle any changes in HTML/structure, barring the problem above about legacy/new), but all old user agents, integrated user agents in things like smart TVs etc, old versions of browsers that still need to work, utility libraries / components that form part of larger frameworks/SDKs/applications that consume HTML The second point is arguably a problem for any new feature development. But at the very least if a *new* structure/markup construct/element is proposed, it is generally ignored/fails gracefully on older UAs. Redefining the structure/behavior of a construct that is already deployed, however, causes more complicated failure scenarios. IMO, of course, P -- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Thursday, 24 November 2016 09:07:55 UTC