- From: Alex Danilo <alex@abbra.com>
- Date: Wed, 25 Aug 2010 22:13:33 +1000
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: www-style@w3.org, www-svg <www-svg@w3.org>
Hi Boris, You have some good points, all supporting my point of view... See below: --Original Message--: >On 8/25/10 5:25 AM, Alex Danilo wrote: >> Modal? >> >> You're kidding right. >> >> Here we go, quirks mode, modal CSS parsers. > >Well, that's what happens when two different groups specify syntax that >is almost but not quite identical and you want to support both syntaxes. Yes. > You have the choice of writing two separate but very similar parsers >or one parser with a mode switch. I'm not sure what you complaint is, >exactly. I didn't realise it was a complaint. More like an observation that decades of educational institutions seem to think that exponential notation is a valid way to represent numbers and that the CSS WG has somehow decided that "people don't understand them", etc. You as an implementor should be objecting to having to deal with the different parsing modes, especially when it serves no purpose other than to add to the complexity of a browser and add memory footprint and scope for bugs. There are many camps that argue modal vs. non-modal interfaces but parsing numbers doesn't really fall into that category. >> The web browser of 2020 will likely contain 1 million modal parsing and >> layout modes > >I think most people who write UAs are working rather hard to avoid that. > Some smaller fraction of those who write specs is doing likewise. I totally agree with you here. And the people writing the specs should learn to listen from the implementors who tell them that perhaps your spec could be changed for the better rather than stubbornly arguing their point of view at the detriment of the overall community. If "implementers will implement it that way anyway" then perhaps it's a signal that the spec is short-sighted and could do with some correcting and/or clarification to better reflect what the actual people writing the code need to handle, and it's not what's in the spec all the time as I'm sure you'd agree. >> Some days I wonder if the lunatics are really running the asylum... > >This is the web. It's "run" by people who write web pages, by and >large. What you think of them is up to you. Wrong. <rant> This is not "run" by people that write web pages. It's run by browser implementers, and secondarily by the standards bodies that try to influence the direction of the browser writers. Years ago I remember Tantek making a comment at a BOF table that all the standards setting and namespace stuff was irrelevant since all that people care about was HTML4, CSS1 and a few embellishments. He was correct to a point, but that is the crux of the problem. I have worked on a large project whose analysis was that 99.6% of all web pages out in the field violate the HTML spec. So, it comes down to error handling. The maxim "be prudent in what you generate, and generous in what you consume" has historically been the path to hell for interoperability on the web. The "people" that "run" the web by writing rubbish and testing it in one browser are innocent parties, the guilty ones are the web browser implementers that think it's OK to render anything that's almost correct, mixed order of tags, etc, etc. So we have the situation that there are only perhaps 4 main implementations of the "web" and the code-bases represent probably hundreds of man-years of work and are likely to be unchallenged by any new entity due to the sheer legacy mess that exists. Office, anyone... The HTML5 effort is commendable for trying to lock down the browser specific behaviour in a form that can be replicated by others, the HTML5 parsing algorithm being a prime example. But, given all that - the working groups doing this work seem to have lost sight of the KISS principle. Keep It Simple Stupid. To be forced to have a modal or duplicated parsing code with minor differences violates the KISS principle, doesn't at all align with Agile DRY and pragmatic ideals nor benefits anyone. I have yet to meet a single graphic artist who hand edits HTML/XML/CSS/SVG to produce web graphics. Yet those are the people we are meant to serve. The web is not "run" by people who write web pages, the artists are the real originators of what is arguably the best content. They don't care about whether their tool generates weird tags that may or may not include scientific notation, but you can bet that coping with generation and parsing of the notation on a conditional basis is a pain both for the authoring tool implementor and the browser implementor. In the '80s we entered the supposed WYSIWYG age where the content was king and the file format, namely the markup was invisible and secondary. Only a fool would think that the bulk of the web would be authored in emacs. My point is that if an implementor of any W3C spec. has to write _any_ extra code to implement an arbitrary restriction that has no basis in functionality, then that is a bad thing. Also, geeks on standards bodies are not the primary content generators for compelling content, and so are the last people who should be debating "what people understand" when the thing being understood should be an opaque file format. When was the last time anyone hand edited a Flash file... </rant> Fire away, Alex >-Boris > > >
Received on Wednesday, 25 August 2010 12:18:19 UTC