HTML5 support with Dreamweaver
21 views
Skip to first unread message
William Wilson
Jun 12, 2011, 11:43:50 PM6/12/11
to lif...@googlegroups.com
Hello all,
I'm the developer of a project working with a not-very-technical web designer who uses Dreamweaver. We want to use HTML5 rather than XHTML because of the problems with XHTML especially on IE. Our idea is that she will design the page, then I will take it and add the Lift tags to tie in the dynamically generated content, and she should even be able to go back and edit the document as long as I stick to designer-friendly tags. I'm confused though about how to get this to work, if it is practical at all. Dreamweaver can output HTML5, and it can also output XHTML, however the HTML5 output is not also XML, and so Lift will not work with it. I'm not sure the best way to proceed here. I can get the XHTML output, pretend it is HTML5, maybe change the doctype and such, and see what happens. This is straightforward enough that the build script can do it, but it seems kind of unlikely to work in the long term on nontrivial pages (in the sense of the browser actually displaying what we expect it to). Converting the Dreamwoven HTML5 into something that's also valid XML seems hard, and Dreamweaver in HTML5 mode will probably mangle it every time she makes any changes.
Is there anybody out there who is in a similar situation? Most HTML5 references suggest that keeping strict XML compatibility in HTML5 is very difficult. The "designers don't have to be coders" idea is part of why I want to use Lift, but I'm worried that won't really be possible working in the HTML5 world.
I'm the developer of a project working with a not-very-technical web designer who uses Dreamweaver. We want to use HTML5 rather than XHTML because of the problems with XHTML especially on IE. Our idea is that she will design the page, then I will take it and add the Lift tags to tie in the dynamically generated content, and she should even be able to go back and edit the document as long as I stick to designer-friendly tags. I'm confused though about how to get this to work, if it is practical at all. Dreamweaver can output HTML5, and it can also output XHTML, however the HTML5 output is not also XML, and so Lift will not work with it. I'm not sure the best way to proceed here. I can get the XHTML output, pretend it is HTML5, maybe change the doctype and such, and see what happens. This is straightforward enough that the build script can do it, but it seems kind of unlikely to work in the long term on nontrivial pages (in the sense of the browser actually displaying what we expect it to). Converting the Dreamwoven HTML5 into something that's also valid XML seems hard, and Dreamweaver in HTML5 mode will probably mangle it every time she makes any changes.
Is there anybody out there who is in a similar situation? Most HTML5 references suggest that keeping strict XML compatibility in HTML5 is very difficult. The "designers don't have to be coders" idea is part of why I want to use Lift, but I'm worried that won't really be possible working in the HTML5 world.
Antonio Salazar Cardozo
Jun 13, 2011, 12:25:46 AM6/13/11
to lif...@googlegroups.com
Lift uses an HTML5 parser by default from 2.3 (or maybe 2.2?) onwards; it does not require any sort of strict XML compatibility. However, if Dreamweaver makes mistakes in how it outputs its HTML5 -- in particular, if it outputs HTML5 in a structure that isn't correct according to the standard -- then the parser may change how it interprets the information. That said, if DW claims it's outputting HTML5, it shouldn't be a problem.
Thanks,
Antonio
William Wilson
Jun 13, 2011, 1:20:48 AM6/13/11
to lif...@googlegroups.com
That is what I had originally hoped, but I find information like this:
https://groups.google.com/d/msg/liftweb/UCpKrM7f88g/jQRAKGpbA74J
and additionally if the content is not truly XML, then it opens the additional question of what would be the meaning of the NodeSeq types that Lift code operates on.
Simply trying it to see if it would work resulted in errors, hence my post and general confusion.
https://groups.google.com/d/msg/liftweb/UCpKrM7f88g/jQRAKGpbA74J
and additionally if the content is not truly XML, then it opens the additional question of what would be the meaning of the NodeSeq types that Lift code operates on.
Simply trying it to see if it would work resulted in errors, hence my post and general confusion.
--To view this discussion on the web visit https://groups.google.com/d/msg/liftweb/-/G3l0eAPYX9gJ.
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.
Tomáš Dvořák
Jun 13, 2011, 5:15:41 AM6/13/11
to Lift
I'm in the very same situation. I haven't found any truly satisfying
solution yet, but have developed a few habits and tricks to make the
situation viable.
- My designer puts the templates in a different directory than
webapp. We only modify these templates, because there is some
automatic additional processing applied to them and the result is
copied to webapp.
- I have a shell script, invoked automatically by sbt, that
translates all the relative links in html (images, css, ...) made by
my designer to absolute links and copies the result to webapp. I'm not
sure if dreamweaver could do this for me.. Maybe I'll rewrite it to
scala somewhere in the future and use real xml handling instead of
just sed, but it works "good enough" for now. It would also be handy
to move the contents of <head> to <head_merge> at this stage, but I
have told my designer how to do it manually so for now he does it
every time just before commit.
- I try to have it unit tested that all the css binds I define in the
code have a corresponging placeholder tag in the html. This is
probably the most crucial point, because when these tests pass, the
corresponding html files have probably been parsed correctly, and also
I know that nothing was accidentaly deleted or forgotten.
- When something is wrong, the first thing I do is I manually repair
the suspicious xml file so that it passes through xmllint (http://
xmlsoft.org/xmllint.html). That usually helps.
- When everything works, I commit the result and my designer starts
working again on the fresh files.
So, all in all it's just a bunch of ad-hoc steps and manual repairs.
It is surely less then optimal, and I hope that as I learn more Scala
and Lift I will improve the process, but it is good enough so that we
can actually use DW to do the html design.
Hope that helps,
Tomas Dvorak
solution yet, but have developed a few habits and tricks to make the
situation viable.
- My designer puts the templates in a different directory than
webapp. We only modify these templates, because there is some
automatic additional processing applied to them and the result is
copied to webapp.
- I have a shell script, invoked automatically by sbt, that
translates all the relative links in html (images, css, ...) made by
my designer to absolute links and copies the result to webapp. I'm not
sure if dreamweaver could do this for me.. Maybe I'll rewrite it to
scala somewhere in the future and use real xml handling instead of
just sed, but it works "good enough" for now. It would also be handy
to move the contents of <head> to <head_merge> at this stage, but I
have told my designer how to do it manually so for now he does it
every time just before commit.
- I try to have it unit tested that all the css binds I define in the
code have a corresponging placeholder tag in the html. This is
probably the most crucial point, because when these tests pass, the
corresponding html files have probably been parsed correctly, and also
I know that nothing was accidentaly deleted or forgotten.
- When something is wrong, the first thing I do is I manually repair
the suspicious xml file so that it passes through xmllint (http://
xmlsoft.org/xmllint.html). That usually helps.
- When everything works, I commit the result and my designer starts
working again on the fresh files.
So, all in all it's just a bunch of ad-hoc steps and manual repairs.
It is surely less then optimal, and I hope that as I learn more Scala
and Lift I will improve the process, but it is good enough so that we
can actually use DW to do the html design.
Hope that helps,
Tomas Dvorak
William Wilson
Jun 13, 2011, 7:27:48 AM6/13/11
to lif...@googlegroups.com
Looking through what I wrote before, I've learned that the post I cited about needing to have valid XML even in your HTML5 predates the official addition of HTML5 support to Lift, so perhaps it's not true any more.
But I am still confused, if the HTML5 parser doesn't require XML-compatible source, then what is in the NodeSeq's that are passed to the snippets? My understanding is these can only contain XML (or at least I have only ever seen a NodeSeq containing XML), does Scala actually allow these to be HTML also? Or is there some HTML5-in-XML representation used? If so, what is that?
I have found that the problems I am having getting it to work at all are due to some unit tests that were "helpfully" included with the distribution, so when I have terminated these with extreme prejudice perhaps I will have reached the state of being able to get Lift to display some plain HTML.
But I am still confused, if the HTML5 parser doesn't require XML-compatible source, then what is in the NodeSeq's that are passed to the snippets? My understanding is these can only contain XML (or at least I have only ever seen a NodeSeq containing XML), does Scala actually allow these to be HTML also? Or is there some HTML5-in-XML representation used? If so, what is that?
I have found that the problems I am having getting it to work at all are due to some unit tests that were "helpfully" included with the distribution, so when I have terminated these with extreme prejudice perhaps I will have reached the state of being able to get Lift to display some plain HTML.
2011/6/13 Tomáš Dvořák <dvt...@gmail.com>
David Pollak
Jun 13, 2011, 1:20:26 PM6/13/11
to lif...@googlegroups.com
On Mon, Jun 13, 2011 at 4:27 AM, William Wilson <fluff...@gmail.com> wrote:
Looking through what I wrote before, I've learned that the post I cited about needing to have valid XML even in your HTML5 predates the official addition of HTML5 support to Lift, so perhaps it's not true any more.
As of Lift 2.2-M1, there was a choice of using Html5 or XHTML as input (templates) and output (what's sent to the browser) (although the pre-built processors are Html5 in/out and XHTML in/out).
But I am still confused, if the HTML5 parser doesn't require XML-compatible source, then what is in the NodeSeq's that are passed to the snippets?
The fact that Html5 source is not valid XML doesn't mean that there's not a valid DOM representation. In fact, all browsers have an internal DOM representation (see http://www.w3.org/DOM/ ) that is a tree of nodes, just like a NodeSeq represents a tree of nodes.
My understanding is these can only contain XML (or at least I have only ever seen a NodeSeq containing XML), does Scala actually allow these to be HTML also? Or is there some HTML5-in-XML representation used? If so, what is that?
The internal representation of the DOM is the same for XHTML and Html5. The fact that the text representation of the DOM differs does not imply that the internal representation of the DOM must differ.
I have found that the problems I am having getting it to work at all are due to some unit tests that were "helpfully" included with the distribution, so when I have terminated these with extreme prejudice perhaps I will have reached the state of being able to get Lift to display some plain HTML.
All of the examples in http://simply.liftweb.net are written in Html5 and most of them are "designer friendly" (i.e., each page is a valid Html5 page with <html>, <head> and <body> tags). The only system within Lift (that I know of) that does not work correctly with the designer friendly templates is the /templates-hidden/wizard-all.html file which is still a whacky combination of bind()-able nodes.
--
Lift, the simply functional web framework http://liftweb.net
Reply all
Reply to author
Forward
0 new messages