HTML5 support is now in SNAPSHOT

14 views
Skip to first unread message

David Pollak

unread,
Nov 27, 2010, 8:18:06 PM11/27/10
to liftweb
Here's a wiki page on it:
https://www.assembla.com/wiki/show/liftweb/HtmlProperties_XHTML_and_HTML5

Please do a lot of testing against both the legacy XHTML and HTML5 support.

Thanks,

David

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

aw

unread,
Nov 28, 2010, 3:07:28 PM11/28/10
to Lift
The wiki post makes the statement:

"It turns out that most browsers, even modern ones (Firefox,
Chrome and Safari) had issues with XHTML. Further, XHTML limited the
behavior of certain JavaScript libraries."

Can you please elaborate on this? I didn't realize that XHTML had
issues... As far as I knew, there is an XHTML5 too.

The statement, "Tags of the format <div/> and <my_thing:bind/> are not
legal." Is that just a bug with nu.validator, or part of HTML5? This
feels like a step backwards to adjust my templates to replace <x/>
instances to <x></x>.

The "designer friendly div" (<div class="lift:FooBar"></div) is new to
me. Does this mean that the wiki (https://www.assembla.com/wiki/show/
liftweb/Templates_and_Binding) needs to be updated?

David Pollak

unread,
Nov 28, 2010, 3:45:27 PM11/28/10
to lif...@googlegroups.com
On Sun, Nov 28, 2010 at 12:07 PM, aw <ant...@whitford.com> wrote:
The wiki post makes the statement:

   "It turns out that most browsers, even modern ones (Firefox,
Chrome and Safari) had issues with XHTML. Further, XHTML limited the
behavior of certain JavaScript libraries."

Can you please elaborate on this?

There have been a number of jQuery/Firefox related bugs... and the most recent issue was with Chrome not recognizing namespaces in innerHTML.

Also, there are plenty of issues with JavaScript that attempts to write to the DOM (e.g., Google maps).
 
 I didn't realize that XHTML had
issues...  As far as I knew, there is an XHTML5 too.

There is... and I expect that it will also be a less-supported, less tested format... and rather than pushing against the tide, I made the decision to support non-XML HTML5.

But, you can substitute your own parser/formatter, just as we have with the nu.validator code.  It's completely plugable and if you want something else, as long as you can move to/from Scala's XML representation, you're golden.
 

The statement, "Tags of the format <div/> and <my_thing:bind/> are not
legal."  Is that just a bug with nu.validator, or part of HTML5?  This
feels like a step backwards to adjust my templates to replace <x/>
instances to <x></x>.

Feel free to complain to the HTML5 committee.
 

The "designer friendly div" (<div class="lift:FooBar"></div) is new to
me.  Does this mean that the wiki (https://www.assembla.com/wiki/show/
liftweb/Templates_and_Binding
) needs to be updated?

It depends on wether you're using XHTML or HTML5.  Right now, Lift defaults to XHTML and HTML5 is an option.
 

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

Harry-Anton Talvik

unread,
Nov 29, 2010, 11:00:53 AM11/29/10
to lif...@googlegroups.com
Hi,

On Sun, Nov 28, 2010 at 03:18, David Pollak
<feeder.of...@gmail.com> wrote:
> Here's a wiki page on it:
> https://www.assembla.com/wiki/show/liftweb/HtmlProperties_XHTML_and_HTML5
> Please do a lot of testing against both the legacy XHTML and HTML5 support.

So far, I've used following configurations in Boot to get so called
HTML5 support (I want a page with HTML5 DocType served as text/html
and authored in XHTML syntax):
// 1. HTML5 DocType
LiftRules.docType.default.set(
(r: Req) => r match {
case _ if S.skipDocType => Empty
case _ if S.getDocType._1 => S.getDocType._2
case _ => Full(DocType.html5)
})

// 2. text/html mime type
LiftRules.useXhtmlMimeType = false

// 3. No XML header, i.e. no <?xml version="1.0" encoding="utf-8"?>,
// as IE6 goes onto quirks mode seeing this
LiftRules.calculateXmlHeader = (resp, node, contentType) => ""

Without any changes from my part, with new HTML5 support in
2.2.-SNAPSHOT last configuration does not work any more (as
includeXmlVersion in LiftResponse.writeDocType() seems to overrule
it). So, starting from this snapshot I get pages like
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
...
</head>
...
</html>

What is the minimal change one needs to make to remove XML header again?

Thanks,
Harry-A

David Pollak

unread,
Nov 29, 2010, 12:37:00 PM11/29/10
to lif...@googlegroups.com
LiftRules.htmlProperties.default.set((r: Req) => (new Html5Properties(r.userAgent)).setHtmlParser( PCDataXmlParser.apply _))

The above uses HTML5 out, but uses the open PCDataXmlParser... this means that your source is parsed as XHTML.


--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

Harry-Anton Talvik

unread,
Nov 30, 2010, 12:15:46 PM11/30/10
to lif...@googlegroups.com
Hi,

On Mon, Nov 29, 2010 at 19:37, David Pollak
<feeder.of...@gmail.com> wrote:
> LiftRules.htmlProperties.default.set((r: Req) => (new
> Html5Properties(r.userAgent)).setHtmlParser( PCDataXmlParser.apply _))
>
> The above uses HTML5 out, but uses the open PCDataXmlParser... this means
> that your source is parsed as XHTML.

Thank You. This answer was helpful.

Although it does not work for my situation (app uses client side
templating which currently does not play well with PCDataXmlParser),
it provided (en)lightning to the way to fix the issue with XML header
without any notable side effects.

Currently, to do without XML header, I do so:

LiftRules.htmlProperties.default.set(
(r: Req) => (new OldHtmlProperties(r.userAgent)).setHtmlOutputHeader(
() => (new Html5Properties(r.userAgent).htmlOutputHeader)
)
)

Tried also
LiftRules.htmlProperties.default.set(
(r: Req) => (new OldHtmlProperties(r.userAgent)).setEncoding(
() => (new Html5Properties(r.userAgent).encoding)
)
)
or
LiftRules.htmlProperties.default.set(
(r: Req) => (new OldHtmlProperties(r.userAgent)).setEncoding(() => Empty)
)
Those had no effect, XML header still appeared in the rendered document.

Also, I'm wondering what is the role of 'LiftRules.calculateXmlHeader'
now, after recently added HTML5 support. Shall it be deprecated, or in
which situations is it still useful?

Thanks,
Harry-A

David Pollak

unread,
Dec 3, 2010, 7:57:14 PM12/3/10
to lif...@googlegroups.com
I've fixed the incompatibilities between the old docType, contentType, etc. LiftRules features and the new HtmlProperties system.  I'll push the changes to master in a few hours.

On Mon, Nov 29, 2010 at 8:00 AM, Harry-Anton Talvik <harry...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

Reply all
Reply to author
Forward
0 new messages