Henri Sivonen wrote: > The problem with standardizing error messages is that it forbids > competition by providing better error messages.
So, the desired end result of standardized error messages is that, if you don't feel like providing better error messages, you can use something pre-canned. > For example, the Validator.nu HTML Parser maintains tokenizer state that > is unnecessary for parsing per se but useful for error messages. (The > particular bit of state is the source position of the ampersand when > parsing something that might turn out to be a character reference.) > > I think the Validator.nu HTML Parser shouldn't be in violation of the > spec for doing this, but also parsers that don't want to spend cycles > for maintaining message-only state shouldn't be required to. That's a good argument for not including it in the HTML5 spec. Still, the location of "emit a Parse Error" in the HTML5 spec is perhaps the most unambiguous way of specifying these parse errors. Maybe we just publish an alternate version with error names? Cheers, Edward --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "html5lib-discuss" group. To post to this group, send email to html5lib-discuss@googlegroups.com To unsubscribe from this group, send email to html5lib-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/html5lib-discuss?hl=en-GB -~----------~----~----~----~------~----~------~--~---
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4