developing web applications with xhtml: problems and benefits ian graham senior manager, esolutions...
Post on 22-Dec-2015
213 Views
Preview:
TRANSCRIPT
Developing Web Applications With XHTML:
Problems and Benefits
Ian GRAHAMSenior Manager, eSolutions Group Emfisys, Bank of MontrealE: ian.graham@bmo.com or utoronto.ca}W: http://www.utoronto.ca/ian/talks/T: 416.513.5656 / F: 416.513.5590
Talk Outline
Introduction Technical and process issues
Browsers and XHTMLServer-side data managementDynamic content generationConclusions
Browsers and XHTML
Data delivered to browsers as one of two MIME types text/html (HTML data) text/xml (XML data)
Two types handled in very different ways
Browsers and XHTML
HTML Channel Support
Navigator 1--6 Opera 3--6 Lynx IE 3--5.5 ... Basically every
browser
XML Channel Support
Navigator 6 IE 5/5.5 Opera 4
Fewer browsers, with caveats (rendering / processing problems)
HTML vs. XML Channels
HTML channel XML channelLarge set of defined internal general entities forcommon non-ASCII characters and symbols
Only 5 XML-standard predefined generalentities (lt, gt, amp, apos, and quot)
Default formatting properties for all standardHTML elements
No default XHTML formatting properties(exception: Mozilla/Navigator 6)
CSS support for id- and class-based CSSselectors (e.g., div.special, pre#note)
No support
Hard-wired support for functional elements(links, replaced elements [img, object/applet],map etc.)
No support (some support in Mozilla)
No internal DTD subsets: some browserssupports DOCTYPE declarations with nointernal subset (for rendering mode switching)
Supports internal DTD subsets andarbitrary entity declarations, both internaland (sometimes) external
No validation Supports DTD-based (and sometimesschema-based) validation
must omit CDATA sections Supports CDATA sectionsN/A Supports an XML declarationNo namespace support Supports namespaces
XHTML via XML Channel
Mozilla/NN6 “namespace” support
for XHTML namespace
– default formatting properties
Restricted CSS support
No support (yet) for style, link elements
– <?xml-stylesheet .... ?>
IE 5/5.5 No special support for
XHTML (use CSS+XML)
No standardized support for functional markup
Transform XML into HTML:XML+XSLT HTML
Browser Conclusions:
Deliver data as text/htmlMust avoid many XML features
CDATA sections DTD internal subsets (and DTD functionality)
Not supported by HTML processors
XHTML as text/html
Be aware of some XHTML features xml:lang vs. lang attributes (use both) XML declarations (avoid them) empty element tag notation (add space
before trailing “/” character) non-minimized attribute assignments (some
bugs with Opera 3.6) DTD declaration (rendering concerns)
“Safe” XHTML example
<?xml version= "1.0" encoding= "utf-8" ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd" ><html xmlns= "http://www.w3.org/1999/xhtml1" xml:lang= "en-ca" lang= "en-ca" ><head><title> ... </title><meta http-equiv= "content-type" content= "text/html;charset=utf-8" /></head><body>.....</body></html>
whitespacebefore slash
DOCTYPE Switching
New HTML processors render differently depending on DOCTYPE value:
“quirks” mode -- (reproduces various CSS and other layout “errors” of older browsers)
“standards” mode -- (correct behavior, no quirks [supposedly!] )
DOCTYPE Switching
All XHTML DTDs get “standard” mode. Thus the following rule:
quirks mode: omit DOCTYPE strict mode: include an XHTML
DOCTYPE declaration
Summary
Seems like a lot of problems....Not so bad ...
Have to deal with most anyway (e.g., quirky vs. strict)
“patching” often easy to automateBenefits
Reduced markup errors (well-formedness) Migration path to future delivery channels
Markup Guidelines
Use external scripts and CSS style sheetsAvoid CDATA sectionsExternal script, style sheet filesOn output, auto-adjust syntax:
insert space at end of empty-element tags duplicate lang-related attributes strip/insert appropriate DOCTYPE declaration strip XML declaration
Talk Outline
IntroductionBrowsers and XHTMLServer-side data managementDynamic content generationConclusions
Server-Side Management
XHTML reduces errors in composition and rendering phases Well-formedness ensures unambiguous
processing by an HTML or XML processor Barring CSS errors, this means fewer
browser formatting problems
Problems support by content generation tools
Issues:
Limited pool of XHTML authoring tools Most popular page authoring tools designed
for HTML (DreamWeaver, FrontPage etc.) XHTML conversion adds process steps to
authoring– Too complex for most Web authors/designers
Not an issue for organizations with existing XML/SGML processes
Processing Content
Author /edit
View &verify
Publishcontent
Problem detected
A)
Problem detected
Author /edit
View &verify
Publishcontent
Convertto
XHTMLB)
Alternatives
Use XML-aware authoring tools Issues: Cost, non-WYSIWYG nature
Create tightly controlled page “templates” and limit authoring responsibilities Reduces likelihood of markup error
Dynamic content generation Fragment authoring only -- with validation
Talk Outline
IntroductionBrowsers and XHTMLServer-side data managementDynamic content generationConclusions
Dynamic Content
Content from databases SQL, XML, files (plain text or XML fragments)
Can enforce well-formedness in software Either via structured markup generating
functions or true XML-based tools
Reduced numberof markup/formattingerrors
Server-Side Management
XHTMLFragment
XHTMLFragment
XHTMLFragment
HTML / XHTML
pagetemplate
Page generationengine
HTML / XHTML
tobrowser
text strings
XHTML Fragments
XHTML helps reduce errors in composition of pages from fragments: Checking fragment well-formedness ensures
well-formedness of composed content
Even if template is not well-formed, well-formedness of fragments increases rendering reliability of composed product
Easier to control fragment authoring
Roles & Responsibilities
Fragment creation Many individual writers; requires little markup
knowledge; WYSIWYG often not as importantTemplate creation / Management
Fewer, more technically skilled people; can enforce well-formedness
Fragment Creation
Common use case in content creatione.g., Newspaper articles, weblogs
Subset of XHTML (e.g., p, a, br, h3, b, i, img, em)
few attributes Easy to write Easy to dynamically “correct” markup
Example Web Interface
Advantages
• Centralized code • Single interface
Disadvantages
• Crappy editor• Need to know markup to write content
Future Alternatives
Editable Web content (IE 5.5, Mozilla) http://standardbrains.editthispage.com/
Accessing DOM tree to build an editor DOM ensures validity / well-formedness of
markup
With Mozilla, will work with XML
Content Assembly
Many tools (JSP, php, ASP, zope ...) Not many that guarantee well-formed XML
output Obvious choice: XSLT
Guarantees well-formedness of output HTML output mode allows for most issues
described earlier
Server-Side Management
XHTMLFragment
XHTMLFragment
XHTMLFragment
XSLTpage
template
XSLT processor
XHTMLto
browser
Zero markup / formatting errors
text strings
XSLTfragmenttemplate
XSLT
(2)
Output(2)
XSLT Advantages
Always well-formed! Abstraction layer
between content and output Easier adjustment for
future delivery channels
XSLT
(1)
XSLT
Output(1)
XSLT Caveats
Non-trivial language (well, at least to page developers/designers)
Unclean separation between designer and programmer
Lack of easy integration to common editing tools
Alternative Approach
“Procedural” page template designs XHTML-compliant design tools
Escape to XSLT for content “components” “Prototype-based” transformations
Markup Model
...regular markup ....<xsl:prototype> <table> ... Example table content goes here ... </table></xsl:prototype>... More XHTML markup ....
Talk Outline
IntroductionBrowsers and XHTMLServer-side data managementDynamic content generationConclusions
Conclusions
XHTML provides pragmatic advantages Improved content reliability, at several layers;
migration path to XML-centric world
Several disadvantages in near-term Poor integration with authoring tools; no easy
XSLT-design separation
Developing Web Applications With XHTML:Problems and Benefits
Ian GRAHAMSenior Manager, eSolutions Group Emfisys, Bank of MontrealE: ian.graham@{bmo.com or utoronto.ca}W: http://www.utoronto.ca/ian/talks/T: 416.513.5656 / F: 416.513.5590
top related