Subject: Re: SVG crosswordplayer first release!! - msg#00032

Previous Message by Date: click to view message preview

Re: SVG crosswordplayer first release!!

On Sunday, December 7, 2003, 2:44:40 PM, Jim wrote: JL> "Chris Lilley" <chris@xxxxxx> >> JL> Sure, but requiring that all legacy content need be upgraded so the JL> legacy >> JL> content can be accessed on the new viewers is a very bad idea, the new >> JL> viewers will be seen to be at fault not the content. >> >> No, the reverse. If there is no message then the viewers that don't >> implement old broken stuff are seen to be at fault. If there is a >> message then its clear which content is broken. JL> I don't buy that, I've seen lots of people moan like mad when browsers have JL> switched to standard behaviour Uh, did you switch sides? you are arguing my point. Yes, if you don't flag the errors early on then you can't switch later; people moan about the rendering being 'different' and you are stuck there forever. JL> from non-standard, a lot of people don't JL> care, they need something that works. No, they think they want something that works. In fact they want something that works in their one browser that they developed it for and that they showed to the client to get paid; whether it works on any other browser is dealt with by ostrich tactics. JL> This is why RFC 2854 tells authors of JL> UA's that they have to bugwards compatible with other UA's. JL> We can't JL> break legacy content, We can always break legacy content. We just have to evaluate the amount of it that there is, the fluidity of the market, how much correct content there is, and how young the market is. HTML spent its entire lifetime being broken. It spent some time pretending to be SGML while never seriously expecting anyone to implement it like that, which was a disaster. SVG has a much better footing. Its already intolerant of WF errors, something that HTML has yet to achieve. SVG does have a small legacy of ASV3-specific brokenness. That can be cleaned up and fixed, or it can be left to rot and diluted out by much more good content, or it can rot and spread to all the rest and be supported evermore and eventually added back to SVG 3.0 as a bugfix (holds nose and mutters "DOM 0") so that all the SVG renderers can add duplicate support for stuff that was never in the standard anyway. JL> we can only build something better that authors will JL> want to author to. >> Remember this isn't 'legacy' as in 'it was previously a standard' but >> legacy as in 'nonstandard, proprietary extensions, relying on bugs in >> a particular viewer'. JL> bugs? onkeydown was hardly a bug, it's simply a problem of DOM events not JL> being ready - it was even in the drafts wasn't it - so to get SVG 1.0 out, JL> implementation experience was solicited, people had to implement it, we JL> shouldn't penalise people for doing that. Ah , okay. If something was in SVG 1.0 Rec then yes, deprecation has to be more carefully handled. I am talking about the borken jey stuf and the filling zero width rectangles to get hairlines and silly getFoo methods that were added as a temporary hack to owrk in Netscape 4.x and stuff like that. Because I see implementors asking about those, and trying to implement them to work with existing content, and I want to avoid that. >> And without an error message, yes, new viewers will be seen to be at >> fault. So they will be under pressure to reverse engineer bugs etc and >> the format gets defined by reverse engineering and impenetrable >> hueristics, not by the spec. JL> but with an error message, we have no reason to upgrade as our content we JL> are used to accessing no longer works - that's much more important than new JL> features, we won't know about those until after we've upgraded, and if we JL> never do. This is quite apart from the systems that use an embedded viewer JL> to display content - having legacy ones of these break will be unacceptable JL> so the UA authors will not include it, they'll lose their customers. >> hence the sorry state of html browsers today that have not >> improved significantly in three or four years. JL> Well you know I'd say that there's been no reason to improve, there's been JL> no new mark-up language features, There has been plenty of reason to improve, both decent CSS and interoperable DOM scripting require an actual parse tree that is - gasp! - the same in two different browsers. But they don't get it, so its a mess. They don't get it because the weight of broken legacy to good stuff is zillions to one. JL> and XHTML is still broken. What improvement did you expect from JL> HTML UA's? I don't expect any improvement from HTML UAs, at this point, ever. They are f***ed and will stay that way for ever. Which means that, for example, CSS3 will only ever be implemented by a non-HTML UA. -- Chris mailto:chris@xxxxxx

Next Message by Date: click to view message preview

Re: SVG crosswordplayer first release!!

On Sunday, December 7, 2003, 4:41:35 PM, Jim wrote: JL> "Chris Lilley" <chris@xxxxxx> wrote in message JL> news:662995667.20031207150919@xxxxxxxxx >> SVG has a much better footing. Its already intolerant of WF errors, JL> Unfortunately... are you *mad*???? JL> although at least it's not very intolerant like XHTML, XHTML tolerates wf errors just fine, unfortunately, at least when served as text/html. JL> it JL> still renders what it does understand up to that point. It renders up to the point of NWF, yes. That means the author can figure out where the error is and fix it. >> That can be cleaned up and fixed, or it >> can be left to rot and diluted out by much more good content, or it >> can rot and spread to all the rest and be supported evermore and >> eventually added back to SVG 3.0 as a bugfix (holds nose and mutters >> "DOM 0") so that all the SVG renderers can add duplicate support for >> stuff that was never in the standard anyway. JL> I think our difference is that you're suggesting FooSVG UA 6 has to display JL> an error about something it successfully rendered in FooSVG UA 5 That depends on whether whatever FooSVG UA 5 renders is correct according to some Rec or not. JL> - that I JL> think is wrong, I'd be much happier if you simply said Conformant SVG UA's JL> must not implement a particular feature, Ok, we both want these to be not implemented; just have different ideas on how to get there. My ideas are based on quiet corridor conversations with SVG implementors who say 'we are going to implement blah; its not in the spec but there is content out there using it and it works in other viewers so it has to work in ours too. I am reminded of an anecdote about the author of the 'make' program. He suddenly woke up in bed and realized there was a colossal error, and he knew how to fix it. But then, he realized it was too late to change it, because he already had six users. JL> rather than error on it - my JL> problem is the errors, not the lack of support. Errors which users cannot JL> understand are no use to anyone. I understand where you are coming from. I disagree, though. Errors which users cannot understand are an embarrassment to the author, and ths the author fixes them. Also, many times the author uses a UA to 'see if it works'. For that particular user, the error is very helpful. >> Ah , okay. If something was in SVG 1.0 Rec then yes, deprecation has >> to be more carefully handled. I am talking about the borken jey stuf >> and the filling zero width rectangles to get hairlines and silly >> getFoo methods that were added as a temporary hack to owrk in Netscape >> 4.x and stuff like that. JL> Yeah, the script ones - script errors are fine, I'd encourage those, but JL> script is different to mark-up well written script today can deal with JL> future errors, we can build future-proofing into our scripts (either by JL> try/catching away the errors, or object detection) we can't do the same JL> with mark-up or CSS. That is a fair point. JL> I can't afford to change the content I ship today next JL> year, there's not the budget, I need to be happy that it won't confuse users JL> in the future. Then check that it is compliant. If you as a developer consciously depend on a rendering bug, an undocumented feature, then that is your choice and your risk; don't come crying to me if it doesn't work next year or doesn't work on a different viewer. >> Because I see implementors asking about those, and trying to >> implement them to work with existing content, and I want to avoid >> that. JL> Yep me too! I just think forcing errors to appear is not the way to go. Instead, you suggest merely a spec that says 'don't do that'? >> There has been plenty of reason to improve, both decent CSS and >> interoperable DOM scripting require an actual parse tree that is - >> gasp! - the same in two different browsers. JL> I think us scripters have been more than able to keep DOM scripting alive JL> with different parse-trees, you can also find some research over on wai-er JL> awhile back I did which showed that the browser DOM trees were actually JL> pretty similar. 'pretty similar' is pretty useless. Identical is a lot better. JL> Assuming you get a specific parse tree is impossible in JL> scripting, No,it isn't. The rules for parsing XML are pretty clear. JL> and a mistake (accessibility or other users modify the parse tree JL> for their own needs client-side, we need to cope with that, it's not just JL> bad DOM's that are problem.) Non-sequiteur. I didn't ask for a static parse tree, but a repeatable one. JL> CSS is a different issue for sure. >> They [HTML UAs] are f***ed and will stay that way for ever. JL> I think we can agree on that! And I don't want SVG to go the same sorry route. -- Chris mailto:chris@xxxxxx

Previous Message by Thread: click to view message preview

Re: SVG crosswordplayer first release!!

On Sunday, December 7, 2003, 2:44:40 PM, Jim wrote: JL> "Chris Lilley" <chris@xxxxxx> >> JL> Sure, but requiring that all legacy content need be upgraded so the JL> legacy >> JL> content can be accessed on the new viewers is a very bad idea, the new >> JL> viewers will be seen to be at fault not the content. >> >> No, the reverse. If there is no message then the viewers that don't >> implement old broken stuff are seen to be at fault. If there is a >> message then its clear which content is broken. JL> I don't buy that, I've seen lots of people moan like mad when browsers have JL> switched to standard behaviour Uh, did you switch sides? you are arguing my point. Yes, if you don't flag the errors early on then you can't switch later; people moan about the rendering being 'different' and you are stuck there forever. JL> from non-standard, a lot of people don't JL> care, they need something that works. No, they think they want something that works. In fact they want something that works in their one browser that they developed it for and that they showed to the client to get paid; whether it works on any other browser is dealt with by ostrich tactics. JL> This is why RFC 2854 tells authors of JL> UA's that they have to bugwards compatible with other UA's. JL> We can't JL> break legacy content, We can always break legacy content. We just have to evaluate the amount of it that there is, the fluidity of the market, how much correct content there is, and how young the market is. HTML spent its entire lifetime being broken. It spent some time pretending to be SGML while never seriously expecting anyone to implement it like that, which was a disaster. SVG has a much better footing. Its already intolerant of WF errors, something that HTML has yet to achieve. SVG does have a small legacy of ASV3-specific brokenness. That can be cleaned up and fixed, or it can be left to rot and diluted out by much more good content, or it can rot and spread to all the rest and be supported evermore and eventually added back to SVG 3.0 as a bugfix (holds nose and mutters "DOM 0") so that all the SVG renderers can add duplicate support for stuff that was never in the standard anyway. JL> we can only build something better that authors will JL> want to author to. >> Remember this isn't 'legacy' as in 'it was previously a standard' but >> legacy as in 'nonstandard, proprietary extensions, relying on bugs in >> a particular viewer'. JL> bugs? onkeydown was hardly a bug, it's simply a problem of DOM events not JL> being ready - it was even in the drafts wasn't it - so to get SVG 1.0 out, JL> implementation experience was solicited, people had to implement it, we JL> shouldn't penalise people for doing that. Ah , okay. If something was in SVG 1.0 Rec then yes, deprecation has to be more carefully handled. I am talking about the borken jey stuf and the filling zero width rectangles to get hairlines and silly getFoo methods that were added as a temporary hack to owrk in Netscape 4.x and stuff like that. Because I see implementors asking about those, and trying to implement them to work with existing content, and I want to avoid that. >> And without an error message, yes, new viewers will be seen to be at >> fault. So they will be under pressure to reverse engineer bugs etc and >> the format gets defined by reverse engineering and impenetrable >> hueristics, not by the spec. JL> but with an error message, we have no reason to upgrade as our content we JL> are used to accessing no longer works - that's much more important than new JL> features, we won't know about those until after we've upgraded, and if we JL> never do. This is quite apart from the systems that use an embedded viewer JL> to display content - having legacy ones of these break will be unacceptable JL> so the UA authors will not include it, they'll lose their customers. >> hence the sorry state of html browsers today that have not >> improved significantly in three or four years. JL> Well you know I'd say that there's been no reason to improve, there's been JL> no new mark-up language features, There has been plenty of reason to improve, both decent CSS and interoperable DOM scripting require an actual parse tree that is - gasp! - the same in two different browsers. But they don't get it, so its a mess. They don't get it because the weight of broken legacy to good stuff is zillions to one. JL> and XHTML is still broken. What improvement did you expect from JL> HTML UA's? I don't expect any improvement from HTML UAs, at this point, ever. They are f***ed and will stay that way for ever. Which means that, for example, CSS3 will only ever be implemented by a non-HTML UA. -- Chris mailto:chris@xxxxxx

Next Message by Thread: click to view message preview

Re: SVG crosswordplayer first release!!

On Sunday, December 7, 2003, 4:41:35 PM, Jim wrote: JL> "Chris Lilley" <chris@xxxxxx> wrote in message JL> news:662995667.20031207150919@xxxxxxxxx >> SVG has a much better footing. Its already intolerant of WF errors, JL> Unfortunately... are you *mad*???? JL> although at least it's not very intolerant like XHTML, XHTML tolerates wf errors just fine, unfortunately, at least when served as text/html. JL> it JL> still renders what it does understand up to that point. It renders up to the point of NWF, yes. That means the author can figure out where the error is and fix it. >> That can be cleaned up and fixed, or it >> can be left to rot and diluted out by much more good content, or it >> can rot and spread to all the rest and be supported evermore and >> eventually added back to SVG 3.0 as a bugfix (holds nose and mutters >> "DOM 0") so that all the SVG renderers can add duplicate support for >> stuff that was never in the standard anyway. JL> I think our difference is that you're suggesting FooSVG UA 6 has to display JL> an error about something it successfully rendered in FooSVG UA 5 That depends on whether whatever FooSVG UA 5 renders is correct according to some Rec or not. JL> - that I JL> think is wrong, I'd be much happier if you simply said Conformant SVG UA's JL> must not implement a particular feature, Ok, we both want these to be not implemented; just have different ideas on how to get there. My ideas are based on quiet corridor conversations with SVG implementors who say 'we are going to implement blah; its not in the spec but there is content out there using it and it works in other viewers so it has to work in ours too. I am reminded of an anecdote about the author of the 'make' program. He suddenly woke up in bed and realized there was a colossal error, and he knew how to fix it. But then, he realized it was too late to change it, because he already had six users. JL> rather than error on it - my JL> problem is the errors, not the lack of support. Errors which users cannot JL> understand are no use to anyone. I understand where you are coming from. I disagree, though. Errors which users cannot understand are an embarrassment to the author, and ths the author fixes them. Also, many times the author uses a UA to 'see if it works'. For that particular user, the error is very helpful. >> Ah , okay. If something was in SVG 1.0 Rec then yes, deprecation has >> to be more carefully handled. I am talking about the borken jey stuf >> and the filling zero width rectangles to get hairlines and silly >> getFoo methods that were added as a temporary hack to owrk in Netscape >> 4.x and stuff like that. JL> Yeah, the script ones - script errors are fine, I'd encourage those, but JL> script is different to mark-up well written script today can deal with JL> future errors, we can build future-proofing into our scripts (either by JL> try/catching away the errors, or object detection) we can't do the same JL> with mark-up or CSS. That is a fair point. JL> I can't afford to change the content I ship today next JL> year, there's not the budget, I need to be happy that it won't confuse users JL> in the future. Then check that it is compliant. If you as a developer consciously depend on a rendering bug, an undocumented feature, then that is your choice and your risk; don't come crying to me if it doesn't work next year or doesn't work on a different viewer. >> Because I see implementors asking about those, and trying to >> implement them to work with existing content, and I want to avoid >> that. JL> Yep me too! I just think forcing errors to appear is not the way to go. Instead, you suggest merely a spec that says 'don't do that'? >> There has been plenty of reason to improve, both decent CSS and >> interoperable DOM scripting require an actual parse tree that is - >> gasp! - the same in two different browsers. JL> I think us scripters have been more than able to keep DOM scripting alive JL> with different parse-trees, you can also find some research over on wai-er JL> awhile back I did which showed that the browser DOM trees were actually JL> pretty similar. 'pretty similar' is pretty useless. Identical is a lot better. JL> Assuming you get a specific parse tree is impossible in JL> scripting, No,it isn't. The rules for parsing XML are pretty clear. JL> and a mistake (accessibility or other users modify the parse tree JL> for their own needs client-side, we need to cope with that, it's not just JL> bad DOM's that are problem.) Non-sequiteur. I didn't ask for a static parse tree, but a repeatable one. JL> CSS is a different issue for sure. >> They [HTML UAs] are f***ed and will stay that way for ever. JL> I think we can agree on that! And I don't want SVG to go the same sorry route. -- Chris mailto:chris@xxxxxx