Re: default for using ' in OutputOptions?

At 04:06 PM 6/26/2003 +0200, you wrote:
>On Èt, 2003-06-26 at 15:48, Jacob Kjome wrote:
> > The defaults would be entirely non-quirks oriented.
>
>Then the XMLC should document that for XHTML output it needs to enable
>the following quirks:
>
>- setUseAposEntity(false)
>- setScriptTagCompatibility (sorry I forgot the real function name)
>- and perhaps something else?

Yes, documentation is always good.  I think the point is that XMLC should 
not force the quirks by default.  It should be up to the developer to 
determine what is required for compatibility in their particular situation.

> > Does that  make more sense?
>
>I don't know. Last time you proposed that the browser compatibility is
>the one of the most important things in the XMLC output and I agreed at
>last.

I don't think that I've really changed my tune here.  The problem before 
was that XMLC didn't provide a mechanism for all the compatibility issues 
that might come up.  Now it does.  That doesn't mean quirks to provide 
compatibility for certain browsers should be on by default.  For instance, 
the get/setDropHtmlSpanIds() option was forced to "true" in the 
HTMLFormatter even though it's default in OutputOptions was 
"false".  Dropping id's on <span> tags is not desired behavior in most 
cases.  The only reason it was ever done is to get around a bug In IE4.0 
(which is old news at this point) which only occurred if you were using 
Keep-alive connections.  Having it as an option available to enable this 
compatibility quirk is a good thing, but having it on by default just 
causes confusion and, again, is not the desired behavior in most cases.

So, you are suggesting that we determine some default behavior that works 
with the majority of browsers out there and base the defaults quirks on 
that?  And then if people want to turn off quirks, they can?  It is a valid 
point of view, but I'm not sure that we will do a good job at guessing what 
quirks will be desired by the XMLC community at large, especially since 
some quirks might make sense for some markup (HTML and XHTML), but not 
other markup (XML).  However, doing this would have the advantage not 
forcing so much usage of custom OutputOptions for the majority of 
cases.  If the defaults work for most people, I agree that would probably 
be the most convenient thing.  I'm really going back and forth on this 
issue in my head.  I definitely see your point.

Anyone else with an opinion on this?  Only you can decide how XMLC-2.2 will 
behave by default, so speak up.

Jake

>Petr
>
>
>_______________________________________________
>XMLC mailing list
>[email protected]
>http://www.enhydra.org/mailman/listinfo.cgi/xmlc