Hi,

I would be interested in other examples of where we have problems between
XHTML and HTML5, because, IMO, the target="_blank" example is something
almost everybody can live without (in XHTML for instance), and, indeed,
leave users to open those links in a new tab if that is what they wish (as
a "workaround" for apps that were "relying" on that feature).

So, in other words, for this particular target="_blank" problem, one option
for our applications (that we also validate) would be to not use this
feature at all, so that we validate in both HTML5 and XHTML and that we
don`t commit to either the flamingo skin nor colibri.

Where this is not applicable, my vote obviously goes to moving on to HTML5
and stop dragging dead weight (XHTML). AFAIK, there are no backwards
compatibility issues for HTML5 renderers running with XHTML apps, right?
This [1] is what I managed to find on a quick search, but it does not
suggest problems for HTML5 in supporting XHTML.

Thanks,
Eduard

----------
[1]
http://en.wikipedia.org/wiki/HTML5#Differences_from_HTML.C2.A04.01_and_XHTML.C2.A01.x

On Wed, Apr 8, 2015 at 6:00 PM, [email protected] <[email protected]>
wrote:

> Ok thanks for the example.
>
> I need to think about it a bit more but I don’t like that we break
> existing skins with more recent versions of apps. We also need to start
> preparing for supporting several skins in the future.
>
> Also using the HTML macro with clean=true should be prohibited in the code
> we provide IMO.
>
> Also right now the HTML Cleaner generates valid XHTML, not valid HTML5
> AFAIK so there’s an issue there already, no?
>
> If there’s no way to produce HTML code that is valid both in HTML5 and
> XHTML in our wiki pages then we need to decide what to do:
> * break XHTML compat for all apps from now on
> * break XHTML compat for some apps only (decide which one we break and
> which ones we don’t break)
> * introduce some API to generate HTML (as Denis suggested at some point)
>
> Right now I’m not sure I agree to break XHTML validity for existing xwiki
> instances when they upgrade to XWiki 7.1+ and when they upgrade the apps
> they use.
>
> I need a bit more time to think about this (especially the consequences)
> and probably do a brainstorming session with you.
>
> Thanks
> -Vincent
>
> On 8 Apr 2015 at 16:40:50, Guillaume Louis-Marie Delhumeau (
> [email protected](mailto:[email protected])) wrote:
>
> > And the worse case is the XWiki Syntax help page, where we explicitly
> encourage our users to use the invalid rel="_blank" attribute:
> >
> https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-help/xwiki-platform-help-ui/src/main/resources/XWiki/XWikiSyntaxLinks.xml#L217-217
> >
> > 2015-04-08 16:38 GMT+02:00 Guillaume "Louis-Marie" Delhumeau :
> > > But Vincent, the problem is that these kind of links are present in
> wiki pages too, which do not depend on skins.
> > >
> > > Example, in the watchlist:
> > >
> https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-watchlist/xwiki-platform-watchlist-ui/src/main/resources/XWiki/XWikiUserWatchListSheet.xml#L112-112
> > >
> > > 2015-04-08 16:31 GMT+02:00 [email protected](mailto:
> [email protected]) :
> > > > Hi,
> > > >
> > > > What we need to ensure is that people can still continue to write
> XHTML-valid skins or use existing XHTML skins without problem.
> > > >
> > > > +1 to support only HMTL5 **for the Flamingo skin**.
> > > >
> > > > Thanks
> > > > -Vincent
> > > >
> > > >
> > > > On 8 Apr 2015 at 16:12:02, Guillaume Louis-Marie Delhumeau (
> [email protected](mailto:[email protected])(mailto:
> [email protected])) wrote:
> > > >
> > > > > Hello developers.
> > > > >
> > > > > I am working on making the HTML 5 code of XWiki valid. But in some
> places,
> > > > > I cannot do it without breaking the XHTML validity (which Colibri
> still
> > > > > uses, but this skin is going to be deprecated).
> > > > >
> > > > > Example:
> > > > > in XHTML 1.0, the attribute target="_blank", for links, is
> forbidden. In
> > > > > XWiki, we have "fixed" this by using the attribute rel="_blank"
> instead,
> > > > > and then we have a javascript snippet that dynamically adds the
> > > > > target="_blank" attribute to these links [1]. So the code is valid
> until
> > > > > the javascript is loaded, which is enough to pass our validation
> tests.
> > > > > This is not very clean, since the target="_blank" was forbidden by
> the w3c
> > > > > because they think it should be the user choice to open a link in
> a new
> > > > > window or not. But nobody respects this, and that is why it is no
> longer
> > > > > forbidden in HTML5.
> > > > >
> > > > > The problem we have, is that the value "_blank" is not authorized
> anymore
> > > > > for the "rel" attribute of the links in HTML5.
> > > > >
> > > > > So I propose to remove our workaround, which is useless and
> prohibited for
> > > > > HTML5. As a consequence, we would lose the XHTML validity (which is
> > > > > actually the case when javascript is loaded anyway).
> > > > >
> > > > > WDYT?
> > > > >
> > > > > Guillaume
> > > > >
> > > > > [1] The code that looks for ref="_blank":
> > > > >
> https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-web/src/main/webapp/resources/js/xwiki/xwiki.js#L257
> > > > > _______________________________________________
> > > > > devs mailing list
> > > > > [email protected](mailto:[email protected])
> > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > >
> > >
> > > --
> > > Guillaume Delhumeau ([email protected](mailto:[email protected]
> ))
> > > Research & Development Engineer at XWiki SAS
> > > Committer on the XWiki.org project
> >
> >
> > --
> > Guillaume Delhumeau ([email protected](mailto:[email protected]))
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to