On Sunday 22 November 2009 17:21:11 Evan Daniel wrote: > On Sun, Nov 22, 2009 at 11:51 AM, sashee <[email protected]> wrote: > > > The XHTML support is still broke, and most likely will be in the > > future, as folks at GWT thinks it is low priority ( > > http://code.google.com/p/google-web-toolkit/issues/detail?id=710 ). As > > the XHTML standard is considered low-priority at W3C in favor to > > HTML5, I think treating XHTML as HTML(as of now) won't break sites, > > and GWT is happy too. > > Pretending XHTML is actually HTML doesn't work, because XHTML doesn't > support some features GWT uses, like document.write(); instead it has > alternatives that better separate parsing and scripts. Of course, GWT > simply assumes they are present, rather than using the correct > alternatives. So if you just run the web-pushing code in the XHTML, > it doesn't work. > > If you serve the XHTML with MIME type text/html, then Firefox will do > what the user wants -- in complete disregard for the XHTML spec. The > XHTML spec is very clear that XHTML 1.1 MUST be served as an XML MIME > type, and that failure to do so is an error.
Nonetheless it works with most browsers, right? > > I see 4 basic options. First, we could wait for GWT to support XHTML. Not a good option IMHO, although timing and priorities re merging and enabling web-pushing are debatable... > Second, we could implement a workaround for document.write(); there > are XHTML-compatible javascript functions available that emulate the > document.write() functionality, but I don't know whether they are > sufficiently close to satisfy GWT. Running underneath GWT? Sounds messy... > Third, we could rewrite standards > compliant XHTML into standards compliant HTML. Which would involve...? > And fourth, we could > disable web-pushing on XHTML in the short term while waiting on one of > the first three. Practically speaking IMHO there is a very strong argument for web-pushing, mostly related to connection limits in browsers. > > I am strongly opposed to any decision that results in FProxy > converting standards-compliant XHTML that passes the w3c validator > (for example, my flog) into broken XHTML that doesn't. Ideally, > FProxy would never serve HTML or XHTML that would not pass validation, > and I think we should have that as an explicit goal. However, that's > not realistic, given the difficulty of correcting invalid HTML and the > widespread usage of it. As a lesser goal, I think it's entirely > reasonable to say that FProxy should never turn a standards-compliant > page into one that isn't. (It might still change it, as there's > plenty of standards-compliant stuff that's not safe from a Freenet > perspective.) > > Evan Daniel
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
