- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Wed, 5 Aug 2015 15:10:11 +0300
- To: Hallvord Reiar Michaelsen Steen <hsteen@mozilla.com>
- Cc: Johannes Wilm <johannes@fiduswriter.org>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>
On Wed, Aug 5, 2015 at 12:06 AM, Hallvord Reiar Michaelsen Steen <hsteen@mozilla.com> wrote: > (I'm still worried you're simply moving the complexity of implementing > editing well from the UA implementors to the JS authors. Probably a natural > impulse since the UAs have done a poor job.) I think that's exactly the right thing to do under the circumstances. This is what JS is meant for -- there's absolutely no reason for 95% of editing code to be built into the browsers. Browsers should work on exposing primitives that are difficult for JS writers to do as well, not things that JS writers can do just as well. Browser features are vastly more expensive than JS, because of the need for standardization, multiple implementations, inconsistencies between implementations, users not upgrading their browsers, etc. If there's a problem with a JS library, it can be fixed by the site author in an hour if he has the right tools. Browsers -- good luck. On Wed, Aug 5, 2015 at 9:51 AM, Johannes Wilm <johannes@fiduswriter.org> wrote: > That sounds like a defeatist attitude. In that case I think the word > "deprecated" is correct. Not everything that is marked as "deprecated" > disappears quite as fast as those deprecating it had hoped for. Sometimes > things are even "un-deprecated". But to give up before one even begins > doesn't sound like a healthy attitude. That's just the reality of it, though. This e-mail is encoded in ASCII with hardcoded line breaks at 80 columns because that's the way terminals worked a few decades ago. And if I want anything different . . . I have to encode it as ASCII in base64 with hardcoded line breaks at 80 columns. Packet sizes on the Internet are 1500 bytes because that was was Ethernet switches could take back in the day, so routers need to route millions of tiny packets a second instead of thousands of reasonable-sized ones. The keyboard I'm using is formatted based on what made sense for typewriters. There are tons of other classic examples from all over computing (and outside computing). Once something is entrenched, it's very often stuck for a very very long time, because you can't coordinate everyone to remove it at once. > Also, I do not think that people in 200 years time will keep execCommand > around because someone wrote a webpage in 2007 using it and refuses to > change it now. No, but since browsers in 2015 still have to support it, some people writing new pages will decide they want to use it in their new pages. This may be true indefinitely. So yes, it's *possible* that the feature will be removable at some point in the far distant future. But realistically, the track record for removing this sort of thing is not good. Anyway, I personally don't really care what you call it. But be aware that the word "deprecated" will elicit negative reactions from a lot of people in web standards-land, because it evokes the ideological battles that surrounded XHTML 2 and the creation of the WHATWG, which to some degree are still ongoing today. I think what would make everyone happy is to call it "obsolete", and declare it not to be conforming HTML, but acknowledge that it is still practically part of the web platform for the foreseeable future. That's what Hixie has done for features like this in the HTML spec. Marking it clearly as an obsolete and non-conforming feature should ensure that spec writers don't build on it, and scare away some authors from using it. Nevertheless, having some kind of spec is a good idea in principle, because implementers still do maintain their implementations to some degree, like fixing bugs. I don't know if my spec is actually useful from that perspective to anyone other than me, because it's very complicated and I don't know if it's comprehensible to anyone else without a lot of study that they aren't going to put in. I think it's probably best to keep it around somewhere, but prominently indicate that the feature is obsolete and non-conforming. Is everyone happy with that?
Received on Wednesday, 5 August 2015 12:11:03 UTC