With HTML 5 up, should we continue using the .dhtml and .shtml file formats?
Why does Js and CSS work even when we use HTML, without DHTML. Is this practice wrong?
Is there any advantage of SHTML over PHP?
If these 2 are not deprecated, why aren't they around?
SHTML
There isn't any difference between using .shtml and .php files other than the languages in which they are parsed. .shtml contains SSI scripting, while .php contains PHP scripts. There isn't any specific reason to choose one over the other - it depends completely upon the developer.
DHTML
DHTML isn't a different language or script from HTML. It just refers to the combined use of a markup language (HTML), a client-side scripting language (JavaScript) and a styling language (CSS). It simply notifies that your HTML page has dynamic content.
None of these are deprecated. It is just that SHTML has gone out of use as many people have switched to PHP and other server-side languages, and that people have minimized the usage of the term DHTML for talking about dynamic HTML pages, as now most of the websites have dynamic content.
Related
For context: I am not a web developer or programmer of any sort and I use a screen-reader.
I am using an accessibility evaluation tool across some sites I'd like to visit, which, however, have some accessibility issues.
From some googling, I see that it is fairly easy to specify a single webpages language by using <HTML lang='en'></html> for example for English.
How easy would it be to implement this across an entire site with hundreds of separate pages? This is a very vague question without linking to the specific website. For example, a car website with a separate page for individual cars with each page missing a specified language. Would it be fairly simple to specify the language across all automatically or would one have to manually copy/paste <HTML lang='en'></html> for each page? Or does it heavily depend on how the website was structured HTML-wise? etc.
Thank you
You can define the content language sitewide without modifying the HTML using the HTTP header:
Content-Language: de-DE
This is described in the WCAG : Specifying the default language in the HTTP header
This header should be used as fallback by browsers when no lang attribute is declared.
The HTML5 specification says that if there is no lang attribute on the html tag, and if there is no meta element with the http-equiv attribute set to Content-Language, and if there is only a single language tag in the HTTP header declaration, then a browser may use that information to guess at the default language of the text in the page.
But as noted in the WCAG, this might not be always sufficient:
Note that the Content-Language HTTP header does not serve to identify the language used for processing the content. The content processing language can be identified by means of other techniques, such as the attributes lang and xml:lang in markup languages.
The technique Using the language attribute on the HTML element must be applied and specifiying the lang attribute is something that you won't do an a per-webpage basis, but modifying the site template.
And yes, this is a programming question, a beginner one, but still a programming one
To answer the underlying programming question: Yes, usually changing one file is enough.
You can safely assume that the HTML files that make a website are generated by either a Static Site Generator in advance, or by Content Management System (CMS) on the server when a page is requested.
To generate these files, templates are used. Templates give a common structure and contain variables, which will be replaced by content from the respective page or component.
Usually, there is one main, high-level HTML template, which provides the basic HTML structure with the opening HTML tag <html>.
So usually it suffices to change only one file to include the language attribute, by writing <html lang="en"> in that template, or using a variable for a multi-lingual site <html lang="{{language}}"> (syntax depends on your generator).
I am using HTML to make a websites. I know an alternative languages to markup a website: XHTML, WML. Is there any more markup languages? Can I make a website only with XML or SGML?
Thank you for responses.
There aren't many.
To have a browser make your website viewable, you must provide your website in some language your browser can understand. Just plaintext and HTML work universally, there is quite some SVG and PDF support these days, but the only language you can use that can do all the things most people want a website to be able to do, you will have to use HTML or XHTML in some way. Either through JS or by some templating system, but you'll have to use it to generate what's commonly accepted as being a webpage as far as I'm aware.
That being said, there are some languages like Haml, which can be 'compiled' to HTML so you could use that instead. There are also converters for other XML-based languages and such.
If you want to deliver XML from your server, you can convert it to HTML in the browser using either
(a) XSLT 1.0: nearly all browsers have built in support for XSLT 1.0, which can be invoked using the xml-stylesheet processing instruction embedded in the XML
(b) XSLT 3.0: supported using Saxon-JS, which can be invoked using a small Javascript call in a skeletal HTML page.
(c) CSS: if the XML is reasonably close in structure to what you want to present to the user, you can attach styling properties to the XML elements using CSS.
You can also of course maintain your content in XML and convert it to rendered HTML using XSLT either at publishing time, or when each page is requested using code on the server to do the conversion on demand.
Many scientific journals use XML (actually JATS XML) for publishing scientific articles. XML in this case is transforming to HTML either on server or on client side by javascript. As example you can look here, where taking place client-side transformation. But Google will not index such XML.
I'm currently considering using xsl-fo/fop to generate PDFs out of my Java web application. Parts of the content to be printed are "HTML fragments" (TinyMCE editor in web frontend) from different sources.
Is there a way to "embed" HTML into FOP?
I want to avoid an xslt transformation for individual paragraphs containing HTML fragments (the doc contains a lot of other content as well).
The alternative is to create one HTML/XML document containing all the paragraphs and other content and then apply an xslt transformation over everything, but somehow I'd like to avoid this if possible.
Note: I also considered HTML to PDF engines (e.g. Prince) but they seem to be ludicrously expensive.
Thanks!
No, FOP's only valid input is an XSL-FO file (or XML + XSLT producing XSL-FO, but that's just a convenience option as it's an external library that performs the transformation).
However, you can use / adapt an existing xhtml to FO stylesheets, like those provided by AntennaHouse and RenderX.
Besides, even if you say you don't want to do it, writing an xhtml -> XSL-FO transformation is not a daunting task; this is especially true if the input comes from TinyMCE, as you can configure it to allow only a limited subset of tags, which will require a small set of templates.
(disclosure: I'm a FOP developer, though not very active nowadays)
Is there a tool available which would convert the sources given into HTML with links?
By links I mean that every type, class, and method used would point via href to its definition.
I haven't managed to make highlight, syntax-highlight, nor pygments work this way. Even if it supports input from ctags, it only adds the title attribute, but not links.
Highlight can easily be modified to support things such as adding links to function / class definitions, as well as manual entries.
I was able to hook on to the class and function detection, and have each instance linked to the PHP Manual in my testing. I don't know what you'd want yours to link to, so it's your choice (per language, of course.)
Depending upon the language of your source code you might want to use doxygen. It supports a variety of source languages and can export the comments to HTML and LaTeX.
Many modern languages, like Java or C# support XML-comments to document the source code. You can then extract these comments into a single XML file by compiling them with special options. From this XML you can then easily produce HTML by adding an appropriate CSS sheet. MSDN documentation, for example, is largely based upon these HTML files generated in automated mode.
From time to time, I see web pages whose content is solely written in XML (not HTML or XHTML). These pages usually have some style sheets (either XSLT or CSS) attached to them which makes them look like any other ordinary web page.
My question is, what are the advantages of such an approach (if any), and why would anyone choose to work this way?
EDIT: If this is a good thing, why is it not widespread?
EDIT 2: Thanks everyone for the great responses. They really enlightened me. I also found this question whose content is also related.
It's easier to generate it programmatically and reuse it for other purposes than displaying as webpage.
Update:
EDIT: If this is a good thing, why is it not widespread?
Not everyone needs to generate it programmatically or reuse it for other purposes than displaying as webpage. It's then easier to use plain HTML.
One possible advantage would be for use of the data of the page in something other than a web browser; that would (presumably) be easier to do if a page's content were well-formed XML. Of course in theory a well-formed, semantic XHTML page should be nearly as able to be parsed, as well.
It can also be easier to generate XML instead of XHTML, depending on the data source.
When you are getting XML data in to your system, and you are supposed to present this XML data then it is much easier to write some XSLT for that XML instead of parsing it using some sort of parser and then presenting the data.
That can be a valid point for using XML instead of XHTML or HTML
Update
To answer your question on why this is not widespread, is because XSTL is tedious and hard to work with. Specifically XPath, which can be for some people quite difficult to use.
Those pages use XSLT to get rendered on the client side. Not every browser (especially older ones) supports rendering XML + XSLT. XML can however be used server-side as template and get transformed to HTML by the application running on the server. I personally don't see any advantages to this approach.
There are a lot more web pages that are written solely in XML than you know. You're only seeing the ones that do the XSLT transformation on the client side. Server-side transformation of XML is not at all unusual, because there's a plethora of things that produce data in XML, and transforming XML to HTML in XSLT is straightforward. You'll never know this is happening if you just look at the HTML, which bears no signs of having been generated via XSLT.
Personally, I don't understand it either though one of the biggest problems is support in IE. I created a skeleton ecommerce site serving XML, transformed by XSLT and styled using CSS. I sorely missed the ability to use XLink and other wonderful XML features. It's also nice to be able to tag the data for what it is. I used a 'menu' tag for the restaurant menus. 'price' tags for prices and so on. If a user clicked on a link to change menus, all I had to do was send the name of the item, the price and the description instead of the complete page. iirc, a 4K or more HTML menu page was only 200 bytes of sent data.
As far as the "one error makes everything crash in XML" type comments, the same is true of any programming language so proper coding should be no bother for programmers and careful HTML/CSS types.
Before anyone says that what I did was actually XHTML...no. I served XML. I did call up XHTML namespaces when needed for links, images and HTML type things but only when necessary.