XHTML style attribute

[Andy Dingley]

As I see it, this is the biggest disadvantage of XHTML.

However it is rather a killer!

Noting Jukka's comments, I may be out of date here. XHTML 1.1 as text/
html may now be permissible. If that's the case then it's usable for
IE, but still not recommended. Parsing behaviour will be as tag soup,
not as XHTML. If you're going to serve tag soup, at least stick to the
original recipe and serve it as HTML 4.01.

If, for the sake
of discussion, we ignore that fact, I really don't see any other
disadvantage of XHTML.

But what are its advantages on the web?

Yeah, I agree on you on this. For this transformation I'm loosing about
5 ms per page.

You're losing more than that - cache performance is the problem, not
page generation. With good front end caching on the server, you will
at worst double your page generation effort. With a poor caching
architecture and a mixture of clients, you effectively remove the
cache altogether. If you're going to browser-sniff like this, you
_must_ (if you care about performance) have a cache architecture that
understands the two different page formats and can cache both
independently. You can do this through a smart cache that understands
content-type, or sometimes more simply by using URL re-writing to
separate the pages entirely (their URLs become distinct, so all caches
see them as different)

I disagree with you on this.

Why? What's the _advantage_ of XHTML? Don't tell me XHTML is
different, tell me why it being different translates into a better end
result.

I see the strict syntax of XHTML (XML) as a good thing.

XML / XHTML syntax is no more strict than SGML / HTML. It's
_different_, but there are still rules. XML has the huge syntactic
advantage here that it's _simpler_, and thus humans other than Jukka
can author it accurately. I certainly can't author SGML by hand, using
all the optimisations, and get it right without validating. I can do
this for XML, and I can even do this for HTML 4.01 by ignoring many
optional optimisations in favour of a subset that's closer to XML.

Syntax just isn't "strict". The syntax defines a set of rules,
strictness is whether or not they're complied with. _Compliance_to_ a
syntax may be strict or less strict, but that's a matter for how its
_used_ and whether the consumer throws errors or tries to correct for
them. It's not the syntax itself that defines "strictness".

HTML is usually thought of as "less strict" only because the soup-
capable browsers that _parse_ it are less strict (this is one use case
with less strictness, not a formal definition of the syntax's inherent
strictness). There is no way that practical XHTML web browsers can be
able to be any more strict in the forseeable future, even if they're
fed something labelled as "XHTML / XML".

But in a long run, it might be easier to use DOM in JavaScript and to reuse code.

I have no idea what you mean here, or how that's relevant to XHTML /
HTML

XHTML have some benefits because of the strict syntax and
making XHTML code clearer.

XHTML browsers don't have any "strict" compliance to the syntax. The
XML syntax defines a narrower coding style for well-formed documents,
but we know that web authors will get this wrong. XHTML browsers
cannot practically refuse to display the page in that case, they'll
have to do their best to error correct, same as they've done for years
now.

XHTML code (to a competent author) is no clearer than HTML code (to a
competent author).

Non-well-formed XHTML code (from an incompetent author) cannot be
ignored by web browsers, any more than non-well-formed HTML code can.
Otherwise the browser can't display most of the web, which is
obviously useless.

Sorry, I didn't follow you on this one.

The style attribute is only there if the STYLE module is imported
(mind you, for that matter so is <font>, if you import LEGACY too).
Somewhere in the XHTML 1.1 docs there are notes that discourage the
use of inlined style attributes on elements, in favour of inline
stylesheets and #id selectors. I can't claim to care enough to have
exact the citation to hand.

Didn't know about <xslutput>. Don't think I'm gonna use it,

That's a pretty dumb choice then.

I don't see a point in HTML tags like <address> and some others. OK, we
have a tag to use to write addresses,

We don't - that's not what <address> is for. Read the HTML spec.

Nor is this at all relevant to HTML vs. XHTML.

What do you see as a biggest disadvantage of creating
your own XML Schema for the "HTML"?

You can't create one for HTML. You might create one for "HTML" (or
"My HTML with tweaks") but in that case it's no longer standard HTML
and thus it's difficult for browsers to know how to handle it.

I think I can count off all mobile devices then, can't I?

What do you mean? For one thing, the notion of "mobile devices" as a
special web agent class is rapidly diminishing. They're rapidly
becoming simply "web browsers" with attributes of smaller screens and
sometimes lower bandwidth. The old days of a specialised "WML web" or
even XHTML-MP are already past.

 

[XHTML]

However it is rather a killer!

Yeah, IE still holds the majority of the market. But I don't understand
what are you all complaining about. Do you all feel the biggest
disadvantage of XHTML is the fact IE not supporting it, or is it
something in the XHTML you don't like? I didn't get any real, exact and
simple worded reason why not to use XHTML.

But what are its advantages on the web?

I'll answer it below ("What's the _advantage_ of XHTML?")

cache performance

As I'm developing mainly dynamic pages, I don't like cache (like in
proxy servers). Even more, I disable it with HTTP headers.
Two advantages here: I can better track statistics, and I never have
outdated data.
Disadvantage is larger bandwith, but I can live with that.

I do cache CSS and similar files solely for faster page display on
clients computers, and if I'd want to I could apply the cache to the
pages that are meant to be static.

Why? What's the _advantage_ of XHTML? Don't tell me XHTML is
different, tell me why it being different translates into a better end
result.

Simplicity. I use XHTML + CSS + JavaScript for the core development. If
I'd use HTML as well, I'd had some minor problems with JavaScript, but
OK, I already have major problems trying to write code that could be
executed in both IE and other browsers. I sometimes use XML + XLST and
that is built for XHTML. I could use <xslutput> as you suggested in
one of your previous post, but that just makes things complicated.

XML / XHTML syntax is no more strict than SGML / HTML.

Nevertheless, not well formed documents (like in <b><i></b></i>) are
spotted in the early stage. I see that as a benefit.
Sure, you must also validate your XHTML documents because well-formed
document is only one step towards being a XHTML document.

Syntax just isn't "strict".

I meant here well-formed.

That's a pretty dumb choice then.

XML + XLST is meant to be used with XHTML. I don't see a point in
tweaking it to HTML.



To summarize, can you argue on the following:

1) Step towards to eliminating tag soup: using XHTML has a benefit of a
requirement to a documents to be a well-formed (for instance: Firefox
refuses to display the page if they are not).

2) Simplicity: publishing a website and creating XML+XLST requires a
single language, as opposed to two languages doing basically the same thing.

3) Additional features: if I ever wanted to add additional elements to
my document, I can do that through XHTML modules.


Can you summarize benefits of using HTML instead of the XHTML (in simple
words please), and leave out the reason IE not supporting it (yeah, I
still agree that is a major problem)?

 

[Andy Dingley]

Andy Dingley wrote:

Do you all feel the biggest
disadvantage of XHTML is the fact IE not supporting it,

Probably. I don't think too hard about prioritising this beyond the
level of:

* There is no clear advantage to it.

* There is at least one major disadvantage (IE)

From just this little, I can know there's no point (beyond dancing
lessons for the Finnish angels) in looking harder.

I use a _lot_ of XML. I also use a lot of XHTML within my internal
CMS processes. I just don't publish this XHTML onto the WWW, I
transcode it to HTML 4.01.

If you want detail, read the innumerable web rants against XHTML. Some
of them even make sense. Here's the usual canon:

* David Hammond. Beware of XHTML.
http://www.webdevout.net/articles/beware-of-xhtml

* Spartanicus. No to XHTML.
http://www.spartanicus.utvinternet.ie/no-xhtml.htm

* Ian Hickson. Sending XHTML as text/html Considered Harmful.
http://www.hixie.ch/advocacy/xhtml

* Mark Pilgrim. XHTML's Dirty Little Secret.
http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html

* Tommy Olsson. XHTML Is Dead.
http://www.autisticcuckoo.net/archive.php?id=2005/03/14/xhtml-is-dead

* Henri Sivonen. XHTML - What's the Point?.
http://hsivonen.iki.fi/xhtml-the-point/

* Lachlan Hunt. XHTML is not for Beginners.
http://lachy.id.au/log/2005/12/xhtml-beginners

As I'm developing mainly dynamic pages, I don't like cache

As I'm developing mainly dynamic pages, I love caching and couldn't
work otherwise. Try making a big high-traffic site work without it!
There's a difference between effective, accurate, appropriately
lifetimed cached traffic and some always-stale lash-up with expiry
dates in 2038.

Two advantages here: I can better track statistics,

So you think. _Lots_ of problems with that assumption.

and I never have outdated data.

That's nice, but I prefer to do it by controlling caching competently.

Simplicity.

XHTML Appendix C is _more_ difficult to generate competently by XSLT
than HTML.

I use XHTML + CSS + JavaScript for the core development. If
I'd use HTML as well, I'd had some minor problems with JavaScript,

Why? What on earth is going to hurt your JS by using HTML?

I already have major problems trying to write code that could be
executed in both IE and other browsers.

And why is that an issue for HTML vs XHTML ?

I sometimes use XML + XLST and that is built for XHTML.

XSLT is _not_ built for XHTML. Why do you think so?

I could use <xslutput> as you suggested in
one of your previous post, but that just makes things complicated.

As Barbie said, "Math is Hard!"

It's simply not credible to claim "<xslutput> is too complicated",
yet you're still in a position to achieve anything useful with XSLT.

Nevertheless, not well formed documents (like in <b><i></b></i>) are
spotted in the early stage. I see that as a benefit.

Yes, "spotted in an early stage" is one real concrete advantage of XML
over SGML (and thus XHTML over HTML). As a human I can eyeball this
stuff, I don't have to use automatic validation tools to spot it for
me.

However you're mainly writing dynamic pages. When applied to an
automatic generator, this leel of advantage reduces drastically.

Sure, you must also validate your XHTML documents because well-formed
document is only one step towards being a XHTML document.

s/XHTML/HTML/

These are good practices for all web authoring, they're not specific
to XHTML.
For web authoring, they're indeed still far from common for XHTML!
Using XHTML does _not_ stamp out tag soup.

I meant here well-formed.

Syntax isn't well-formed either. It might define well-formedness, but
well-formedness simply doesn't exist until you've created a document
and compared it to the standard. The specifications both define
requirements for well-formedness, neither of them can compel authors
to actually get it right.

XML + XLST is meant to be used with XHTML.

Why? Where does it specify this? XSLT 1.0 requires XML as an
_input_ (XSLT 2.0 doesn't even require that), but it has always had
HTML in its sights as an output syntax.

1) Step towards to eliminating tag soup: using XHTML has a benefit of a
requirement to a documents to be a well-formed

This is no more a requirement for XHTML than it has been for HTML for
years. Empirical evidence suggests that actual compliance for XHTML is
no better than for HTML, if not worse.

2) Simplicity: publishing a website and creating XML+XLST requires a
single language, as opposed to two languages doing basically the same thing.

Which is the extra language that is required to support HTML rather
than just XHTML?
This isn't HTML (the bulk of that above the syntax is the same
knowledge needed for XHTML)
It isn't SGML (HTML is a tiny subset of SGML features)
At most, it's Appendix C of XHTML 1.0. Now that much is _not_ rocket
science!

3) Additional features: if I ever wanted to add additional elements to
my document, I can do that through XHTML modules.

You can't extend XHTML on the WWW, you can't extend it through XHTML
Modules. At _most_ you might get away with using XML Namespaces.
You've always been able to do this with HTML anyway (for attributes
and some uses of new elements, to the same level as XHTMl allows).

The underlying issue is that the web isn't an XML medium or even an
SGML medium. It is, and long has been, a HTML medium. _Possibly_ it
will also support XHTML in the near future. Neither of these is
extensible as you or the W3C optimistically think / hope.

The web is not an SGML medium. SGML is a _generalised_ markup
language, it has big complicated facilities to support this
generalisation. These features, specifically the requirement to have
the relevant DTD available before processing the content document,
have made it impossible to build anything like "the web" out of SGML.
"The web" works by limiting itself to HTML, _one_ single application
of SGML (or SGML-lite). Browsers don't to support generalised SGML
features because they already know that the _only_ content they need
to support _must_ be in HTML (or at least tag-soup inspired by it).
This simplification is what makes the Web (as envisaged by STB-L)
pratical, compare to its many precursors that never achieved its
widespread adoption.

You can extend your published content as much as you like, you might
even do it in a way that's SGML-valid, but you cannot extend the
browser's support for it. You certainly can't do this just by tweaking
a few lines in a DTD! Look at the massive effort needed to actually
add some new feature to a browser, maybe ActiveX, maybe embedded SVG,
even something as simple as RDFa metadata.

The web is tied to _one_ application-specific doctype, that of HTML.
Anything slightly beyond this is painful, anything far beyond it is
publishing into a vaccum, because there just aren't clients that know
how to process it.

None of this changes in the slightest by using XML. The browsers might
now recognise XHTML too, but they still _only_ recognise XHTML too.
You can add a few new attributes with a simple spot of namespacing,
but you still can't make the browsers natively understand what to do
with them.

You might write some client-side JavaScript that understands your
extensions. You could do this in HTML too. XHTML, even XHTML 1.1
modules, won't help you.

With SemWeb techniques you _might_ start to make browsers self-
extensible, but that's a long way off. A new <postal-address> element
could easily use an RDF Schema to indicate that "Process this like a
HTML <div> for rendering" and simultaneously map it onto the Dublin
Core metadata model to indicate broad meaning. It could even do this
for an element <address-thing-com.example.myproject-GUID-0123401234>
that was unique to one single page and never occurred again on the
entire web.

Can you summarize benefits of using HTML instead of the XHTML

* It works. It works for IE.

* It matches the HTML specifications, rather than relying on
additional overlaid "best practices" and a browser bug that doesn't
fully implement a SGML feature it ought to.

* It's easier to generate from XSLT than Appendix C.

 

[eliza81]

Applying multiple styles HTML elements and significance of "!important " attribute in

There can be multiple CSS classes and inline style applied to a single html element. By the default CSS rule, if same style attribute is set with different values on top of a single element, the closest attribute value will dominate in the out put at the browser end. !important is a special attribute that can break the rule, and can force a particular style irrespective of the hierarchy of all the styles applied.

Here is the example, that makes it more clear.

- The following block of code will display the line in Green, due to the CSS class applied to it.
<style type="text/css">
.DivStyle{color: Green;}
</style>

<div class="divStyle">
This is content in the div.
</div>

Eliza