[CLOSED] Live Preview should work for .xhtml files #4658
Comments
|
If the XML syntax already works properly with the new HTML Live Preview feature landing this sprint (including constructs like |
|
Self-closing-tag syntax does work. I think the main thing in XHTML that we don't handle properly is CDATA blocks (which is only legal in foreign tags in HTML5, I believe, but is legal anywhere where character data can occur in XHTML). Our tokenizer handles it, but we don't process it properly as a node during our parsing/diffing/editing phase, so edits to it would probably be ignored, and edits around it might get applied incorrectly. |
|
Thanks for the quick feedback - happy to do some testing/hacking on this. I haven't done any work on Brackets before, so I just set myself up with the latest master branch. I can confirm that simply adding Is the new HTML Live Preview feature on master at this point, or do I need to check out another branch to test my xhtml files out with that feature? I'm not seeing any issues with previewing/editing my content so far, though I haven't tested any files with CDATA blocks yet. |
|
Live HTML has not yet been turned on in master, but will be soon. For now, with Live Development off, go to Debug > Show Dev Tools, switch to console and type |
|
It's now enabled in master. |
|
Just did some testing using the latest master. The bulk of my content works great. As predicted, there is some unpredictable behavior when using CDATA tags.
Debugging this might be beyond me, but I'm happy to take a look - where does the parsing/diffing/editing code that would need adjustment live? Any tips? |
|
It might be rather complicated, unfortunately. The issue is that the way that we map the source structure to the DOM in the browser is by injecting special "data-brackets-id" attributes into tags when we send the file to the browser. We can't do that same hack for non-tag nodes without disrupting the content. So, for text nodes, what we do is just treat the text as "whatever's between the tags", without tracking individual nodes, and just delete/replace all the text between two tags if any of it changes. That's generally fine for text since nothing should really care about a specific text node, but it would be more complex for CDATA because we would need to know which portion of the text was wrapped in CDATA. That said, I don't actually know how CDATA is represented in the DOM--it might be that it just gets turned into ordinary text once you get to the DOM. If that's the case, then this might be easier--we would just treat it as text on the browser side, and just be careful not to parse it for entities. (Since we don't have to map back from the browser to our source, it doesn't really matter if we have to do a transformation on the way to the browser, I think.) |
|
BTW, the relevant code is in src/language, in HTMLInstrumentation.js, HTMLSimpleDOM.js, and HTMLDOMDiff.js, as well as LiveDevelopment/Agents/RemoteFunctions.js. Basically, HTMLInstrumentation takes the HTML in the editor, instruments it with the This code is still under development but we just added a bunch of comments yesterday so it should be more legible :) |
|
Thanks, I'll dive in and see how it looks. For frame of reference - we deal with quite a lot of XHTML content and I've never actually seen a client use CDATA tags around text, only in In fact, the WHATWG says explicitly (when discussing XHTML files served as HTML5): "Do not use CDATA sections (except possibly for script and style tags--see element-specific behavior below or for SVG/MathML)." |
|
Marking move to backlog. I think this is nontrivial, though not terribly difficult. But it also just occurred to me that we probably don't do the right thing even with |
|
Just noticed pull request #5251, enabling Live Preview of SVG files but not LiveHTML updating of SVG. Is it worth enabling that level of "Live" support for XHTML files? Or do you think it's necessary to get LiveHTML in place first? |
|
I think I might have misunderstood the original request here. We could easily enable preview of XHTML files, but without live-as-you-type editing. That's basically what we're doing for SVG. Doing the live-as-you-type editing for XHTML would require us to deal with CDATA and possibly namespaces, so that's what makes that hard. Would it be valuable for you if we just made it so you could easily preview XHTML files without them updating as you type? (They would refresh on save.) |
|
It is valuable for me - I'm in fact doing that locally already. I made the exact same tweak as the SVG support tweak, editing FileUtils.js to include this line:
Live-as-you-type editing would obviously be nice, but updating on refresh is a useful stop-gap solution. |
|
Got it. It's not quite that simple, I think, because from looking at the code it seems like we would try to do live-as-you-type editing any file whose extension is in |
|
Medium pri to me |
|
You're right - in my local tweaked version, Brackets does "try" to do live-as-you-type editing with some very buggy behavior that I detailed earlier in the thread. And I agree with you 100% - it's useful for me to be able to turn on Live Preview even with broken live-as-you-type editing, but in the big picture I don't think any file format should be able to Live Preview with really broken LiveHTML behavior. |
|
I'm using Brackets for EPUB editing. xhtml Preview would be highly appreciated.... ;) |
|
I'm also trying to use editing EPUB content files with a patch |
|
Hi takahashim! |
|
$ git diff
diff --git a/src/file/FileUtils.js b/src/file/FileUtils.js
index 55c418f..d1fb8ad 100644
--- a/src/file/FileUtils.js
+++ b/src/file/FileUtils.js
`@`@ -330,7 +330,7`@`@ define(function (require, exports, module) {
}
/**`@`const - hard-coded for now, but may want to make these preferences */
- var _staticHtmlFileExts = ["htm", "html"],
+ var _staticHtmlFileExts = ["htm", "html", "xhtml"],
_serverHtmlFileExts = ["php", "php3", "php4", "php5", "phtm", "phtml", "cfm", "cfml", "asp", "aspx", "jsp", "jspx", "shtm", "shtml"];
/** |
|
|
|
Thanks for the tip |
|
|
Wednesday Sep 04, 2013 at 21:01 GMT
Originally opened as adobe/brackets#5058
When attempting to Live Preview a file with a .xhtml extension, this error pops up:
"Live Preview Error - Open an HTML file in order to launch live preview"
I've seen this in all Sprints on Windows and Mac, up to and including the latest release (Sprint 30). This happens for any file with a .xhtml extension.
Removing the "x" from the filename fixes the problem - with a .html extension the same content previews in Chrome just fine.
I propose the Live Preview button treat .xhtml files the same as .html files - it looks like that transition was already made for syntax highlighting (#785) a while back.
The use case here (or at least my use case) is editing EPUB 3 content files, which must be XHTML conformant.
The text was updated successfully, but these errors were encountered: