- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 9 May 2012 22:27:43 +0200
- To: Ian Hickson <ian@hixie.ch>
- Cc: Jonas Sicking <jonas@sicking.cc>, Henri Sivonen <hsivonen@iki.fi>, Rafael Weinstein <rafaelw@google.com>, Webapps WG <public-webapps@w3.org>, Yehuda Katz <wycats@gmail.com>
On Wed, May 9, 2012 at 9:51 PM, Ian Hickson <ian@hixie.ch> wrote:
>> I think the proposals here, and the fact that jQuery has implemented
>> context-free HTML parsing, proves that it is technically possible.
>
> I don't think look-ahead and magically determining the parse mode from a
> preparse of the string is really a sane solution. It doesn't handle all
> cases (e.g. it doesn't handle the <style> example I gave), and it results
> in very weird results ("very bad developer ergonomics") for cases like
> "1GB of text followed by <caption>" vs "1GB of text followed by <coption>"
> (where the former loses the text and the latter does not).
Manually providing a context element in order to get SVG parsing is
pretty crappy. There's no really good reason to do so. It would just
mean that as SVG continues to grow in popularity, jQuery-style "throw
a regex against the string to see what context to use" will continue
to be popular/necessary, which is a pretty bad solution for authors,
particularly when we could just *do the right thing* in a way that
works almost all of the time.
Your example about <caption> vs <coption> is a ridiculously rare case.
It seems silly to worry about devs misspelling a particular rare HTML
tag, in a particular situation that's invalid *anyway*, while blithely
dismissing the enormously larger, non-crazy, valid-markup-using
use-case of "I want to create <g><rect/></g> from a string the same
way I can do <div><img></div>."
If you're going to keep bringing this up, please justify why it's
actually something we should worry about. Otherwise, this is a case
that can be summarily dismissed.
~TJ
Received on Wednesday, 9 May 2012 20:35:42 UTC