XHTML style attribute

[Anonymous]

What does this mean "Style Attribute Module Deprecated" on
http://www.w3.org/TR/xhtml11/doctype.html#s_doctype?

Does it mean I shouldn't use <p style="color:red">Some text</p> in my
XHTML 1.1 documents?

I use CSS classes, but what if I need to apply a specific style to a
only single element of my document? Should I define class just for it,
or is it acceptable to use style attribute instead?

Ty

 

[Jonathan N. Little]

What does this mean "Style Attribute Module Deprecated" on
http://www.w3.org/TR/xhtml11/doctype.html#s_doctype?

Does it mean I shouldn't use <p style="color:red">Some text</p> in my
XHTML 1.1 documents?

I use CSS classes, but what if I need to apply a specific style to a
only single element of my document? Should I define class just for it,
or is it acceptable to use style attribute instead?

Give element some ID and add #someID {} rule

 

[Jukka K. Korpela]

Scripsit Anonymous:

What does this mean "Style Attribute Module Deprecated" on
http://www.w3.org/TR/xhtml11/doctype.html#s_doctype?

Did you notice the following sentences sentences in the document?
"This is a draft document and may be updated, replaced or obsoleted by
other documents at any time. It is inappropriate to cite this document
as other than work in progress."

Does it mean I shouldn't use <p style="color:red">Some text</p> in my
XHTML 1.1 documents?

In the absence of any specific technical definition for "deprecated" in
the document, that's pretty much what it means.

But why are you using XHTML 1.1, or XHTML in general, in the first
place? Just use HTML 4.01. Check the past discussions if you need an
explanation.

XHTML 1.1 was an exercise in futility, and the newest draft, over a year
old now, makes it even more pointless. The W3C processes show their
absurd side here. A _draft_ that old, and with such an instability
disclaimer, is advertized as the newest version, despite the fact that
the year 2001 version is still a "W3C Recommendation".

I use CSS classes, but what if I need to apply a specific style to a
only single element of my document? Should I define class just for it,
or is it acceptable to use style attribute instead?

There's no real reason why you couldn't use a style attribute. Neither
is there any good reason to use it, since there are slightly better
structured alternatives, such as using a class attribute _or_ an id
attribute and an appropriate selector. The choice between class and id
when you _expect_ that the rule will only be applied to one element is
more or less a matter of taste, but to be really logical, use class
unless you _know_ that the rule will only be applied to one element only
(in one document) ever, in which case id is the logical choice.

 

[Michael Fesser]

..oO(Jonathan N. Little)

Give element some ID and add #someID {} rule

This would lead to a hundred additional IDs in my stylesheets, simply
because every page may have its own purely decorational side image.
The markup for this is generated by a script and uses an inline style
to define the 'background-image' property.

IMHO 'style' attributes have their use and are the appropriate solution
in some cases.

Micha

 

[XHTML]

...

I agree on this with you. It is unpractical for me to assign stylesheet
identificator just for a single element. It makes my stylesheet less
readable.

 

[XHTML]

But why are you using XHTML 1.1, or XHTML in general, in the first
place? Just use HTML 4.01. Check the past discussions if you need an
explanation.

Well, basically this is the story. I was using HTML 4.01 Strict. The
main difference between HTML 4.01 and XHTML 1.1 are tags like <br/>,
<link/> and the fact I ocasionally need to use <![CDATA[...]]> blocks. I
got used to zhat. On the JavaScript side the main difference is that
element names are returned in lowercase.

XHTML 1.1 was an exercise in futility, and the newest draft, over a year
old now, makes it even more pointless. The W3C processes show their
absurd side here. A _draft_ that old, and with such an instability
disclaimer, is advertized as the newest version, despite the fact that
the year 2001 version is still a "W3C Recommendation".

I agree with you on that. I don't take them seriously (W3C) as I used to.

 

[Jonathan N. Little]

.oO(Jonathan N. Little)


This would lead to a hundred additional IDs in my stylesheets, simply
because every page may have its own purely decorational side image.
The markup for this is generated by a script and uses an inline style
to define the 'background-image' property.

No, you can put page specific styles in a style element in the head. The
style element is not deprecated in xhtml1.1 just then inline style
attribute.

IMHO 'style' attributes have their use and are the appropriate solution
in some cases.

Yes, but xhtml folks want persuade you not to, and to encourage you ro
separate style from the markup.

 

[Michael Fesser]

..oO(Jonathan N. Little)

No, you can put page specific styles in a style element in the head.

Correct. Might be an option if I find the time to rewrite that script.

Micha

 

[Jonathan N. Little]

.oO(Jonathan N. Little)


Correct. Might be an option if I find the time to rewrite that script.

Rewrite that script?


<style type="text/css">
#foo { margin-left: 0; }
#bar { color: #f00; background-color: #fff; }
</style>
</head>
<body>
....

 

[Jonathan N. Little]

Well, basically this is the story. I was using HTML 4.01 Strict. The
main difference between HTML 4.01 and XHTML 1.1 are tags like <br/>,
<link/> and the fact I ocasionally need to use <![CDATA[...]]> blocks. I
got used to zhat. On the JavaScript side the main difference is that
element names are returned in lowercase.

And the added benefit of when you use XHTML 1.1 you can alienate all
those IE users!

 

[Michael Fesser]

..oO(Jonathan N. Little)

Rewrite that script?

I have to rewrite/modify my PHP scripts that generate the markup for the
side image and the document header. Not that difficult, but other things
are more important at the moment.

Micha

 

[XHTML]

> And the added benefit of when you use XHTML 1.1 you can alienate all
those IE users!

I need to use XHTML because of XML+XLST.

And as for website pages, I use PHP to transform from XHTML to HTML. It
intoduces some overhead, but it's working fine.

 

[Jonathan N. Little]

I have to rewrite/modify my PHP scripts that generate the markup for the
side image and the document header. Not that difficult, but other things
are more important at the moment.

I see, depends on how you template your pages.

<?php
//include page specific style base on pageName
if(file_exists( "./inc/styles/${pageName}.php" )) {
include_once("./inc/styles/${pageName}.php");
}
//include page specific javascript base on pageName
if(file_exists( "./inc/js/${pageName}.php" )) {
include_once("./inc/js/${pageName}.php");
}
?>
</head>
....

 

[Jonathan N. Little]

I need to use XHTML because of XML+XLST.

And as for website pages, I use PHP to transform from XHTML to HTML. It
intoduces some overhead, but it's working fine.

Pain in the tookas though!

 

[Andy Dingley]

I need to use XHTML because of XML+XLST.

Two points:

* XHTML 1.0 isn't the same thing as XHTML 1.1

It's possible to use XHTML 1.0 on the web by falling back on Appendix
C. It's impossible to use XHTML 1.1 on the web correctly. You either
rule out access from IE, or you have to break the recommendation. If
you _must_ use XHTML (which isn't usually a good idea anyway), make it
XHTML 1.0 Appendix C, not XHTML 1.1

* You can generate HTML 4.01 from XSLT more easily than you can create
usable XHTML with it. HTML from XSLT is easy, Appendix C is hard.

 

[XHTML]

* XHTML 1.0 isn't the same thing as XHTML 1.1

On offline pages (XML+XLST) I use XHTML and use XHTML compliant browser
to see the content. No problems here.

On public pages I use XHTML but based on header sent from browser I fail
back to HTML 4.01 Strict.

The question isn't really about weather I should use HTML or XHTML. I've
decided I'll go with XHTML. I opened this thread to clarify style
attribute deprecation. It validates even with style attribute so I was
unsure.

To what are you referring when you say that 1.0 isn't the same thing as 1.1?
Is it the Content-Type header? As I understood, 1.0 Strict is pretty
much the same to 1.1, except for some minor differences.

* You can generate HTML 4.01 from XSLT more easily than you can create
usable XHTML with it. HTML from XSLT is easy, Appendix C is hard.

Can you provide me with an example. If I use this XSLT document I get an
error.

<?xml version="1.0"?>

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="/">
<html>
<head>
<title>Some title</title>
</head>
<body>
<br>
</body>
</html>
</xsl:template>

</xsl:stylesheet>


As to my understanding, I must use XHTML in conjunction with XML+XLST
because they are both XML languages and HTML doesn't fit.

 

[Jukka K. Korpela]

Scripsit XHTML:

I opened this thread to clarify style
attribute deprecation. It validates even with style attribute so I was
unsure.

Deprecation pretty much implies that it validates: a deprecated feature
is normally something included into the formal specification (such as a
DTD) but declared deprecated.

As I understood, 1.0 Strict is pretty much the same to 1.1, except for
some minor differences.

You have been misled by the W3C. There are numerous differences that
have not been documented in the proper place but are formally implied by
DTD differences. I never listed down all the differences, for two good
reasons:
1) It would mean a lot of work, and nobody offered to pay me half a cent
for doing the spec writers' work.
2) XHTML 1.1 is an exercise in futility.

 

[Andy Dingley]

On offline pages (XML+XLST) I use XHTML and use XHTML compliant browser
to see the content. No problems here.

That's OK for you, but IE isn't compatible with conformant XHTML,
other than XHTML 1.0 with Appendix C. This can be a problem for the WWW.

You need to fix this for web use. You can either hack it, or you can
do it at least nominally correctly (XHTML 1.0 and Appendix C), or you
can (best option) revert to HTML 4.01

On public pages I use XHTML but based on header sent from browser I fail
back to HTML 4.01 Strict.

Two pages for the same content is a waste of effort. It hurts server
load and cache performance. Even switching Content-type by browser can
hurt caching. As there's no advantage to serving this XHTML, why do
it?

The question isn't really about weather I should use HTML or XHTML.

As the wrong question, you're bound to get the wrong answer.

Until you can arm-wrestle Jukka and win with your convincing
justification of XHTML, then you shouldn't use it. I don't deny the
existence of appropriate uses for it, but they're rare and require
skill. If you can't demonstrate this, you're better off avoiding it.

To what are you referring when you say that 1.0 isn't the same thing as 1.1?

There are 3 relevant differences at least:

* No more XHTML (1.0) Transitional, XHTML 1.1 is all "Strict"

* No more Appendix C, so you _cannot_ serve conformant XHTML 1.1 to IE
and have it work. You just can't do this. If you try, you're no longer
conformant.

* XHTML 1.1 is sniffy about style attributes (can't remember if it's
formally deprecated or just disapproved of).

Can you provide me with an example.

Look up the <xslutput> element, or simply add this to your
stylesheet:

<xslutput
method="html"
version="4.01"
omit-xml-declaration="yes"
standalone="yes"
doctype-public="-//W3C//DTD HTML 4.01//EN"
doctype-system="http://www.w3.org/TR/html4/strict.dtd"
encoding="utf-8"
cdata-section-elements="script style pre"
indent="yes"
media-type="text/html"
/>

If I use this XSLT document I get an error.

<body>
<br>
</body>

That's because that document isn't XML (not well-formed) so thus can't
be XSLT. This issue is about whether the _source_ document (the XSLT
"program") is XML or not. What is generated by the XSLT output
serializer is a different question. Using "<br/>" is the appropriate
way to code a linebreak in an XSLT stylesheet to generate HTML 4.01.
The output of this (using the <xslutput> element above) will be
"<br>".

It's easier to do this than it is to guarantee that an XSLT stylesheet
with <xslutput method=xml" /> will never generate "<br></br>" in an
XHTML Appendix C document.

As to my understanding, I must use XHTML in conjunction with XML+XLST
because they are both XML languages and HTML doesn't fit.

No. Source code isn't the same as the generated output. You get the
same issue with technologies like JSF Facelets too.

 

[Jukka K. Korpela]

Scripsit Andy Dingley:

* No more Appendix C, so you _cannot_ serve conformant XHTML 1.1 to IE
and have it work. You just can't do this. If you try, you're no longer
conformant.

It depends. It seems that the XHTML 1.1 draft that now resides at
http://www.w3.org/TR/xhtml11/
(superseding the XHTML 1.1 _specification_ at that address!) says (note
the order!):

"XHTML 1.1 documents SHOULD be labeled with the Internet Media Type
text/html as defined in [RFC2854] or application/xhtml+xml as defined in
[RFC3236]."

So using text/html is explicitly allowed, and you don't need any
particular permission to apply "HTML Compatibility Guidelines", which
are just an informative description of an authoring style.

And it has Appendix C, though different from App. C of XHTML 1.0.

 

[XHTML]

IE isn't compatible with conformant XHTML,

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

Two pages for the same content is a waste of effort. It hurts server
load and cache performance.

Yeah, I agree on you on this. For this transformation I'm loosing about
5 ms per page. Even though it's not much, when multiplied by number of
page hits, it could be significant. On the other hand, I'm using
significally more time on database connection and data retrival, so at
the end this doesn't sound so bad.

As there's no advantage to serving this XHTML, why do it?

I disagree with you on this. I see the strict syntax of XHTML (XML) as a
good thing. If we look at the page solely as the static final product,
then yeah, it's pretty much the same weather I use HTML or XHTML. But in
a long run, it might be easier to use DOM in JavaScript and to reuse code.
It's pretty much the matter of a choice. For instance, some might like
the fact of the loose type definition in JavaScript because they don't
have to worry about defining the type, but I like strict type
definition. Other example is try - catch block. You can write your
program without any of them but they bring some extra benefit to your
code. The same is with HTML. Sure, you can write any XHTML document as
HTML, but XHTML have some benefits because of the strict syntax and
making XHTML code clearer.

Until you can arm-wrestle Jukka and win with your convincing
justification of XHTML, then you shouldn't use it. I don't deny the
existence of appropriate uses for it, but they're rare and require
skill. If you can't demonstrate this, you're better off avoiding it.

Strict syntax. The major disadvantage of XHTML is lack of support in
some browsers.

* No more XHTML (1.0) Transitional, XHTML 1.1 is all "Strict"

I was writing Strict code before, so I don't take this as a bad thing.
The thing I missed on a few occasions is a Frameset DTD (for some
internal use).

* No more Appendix C, so you _cannot_ serve conformant XHTML 1.1 to IE
and have it work. You just can't do this. If you try, you're no longer
conformant.

As I understood from Jukka's last post and as I read from the XHTML 1.1
(draft) page, the problem is solved (IE and similar browsers get tag
soup, but they display the page).

* XHTML 1.1 is sniffy about style attributes (can't remember if it's
formally deprecated or just disapproved of).

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

Look up the <xslutput> element, or simply add this to your
stylesheet:

Didn't know about <xslutput>. Don't think I'm gonna use it, but thanks
for the info.




I don't see a point in HTML tags like <address> and some others. OK, we
have a tag to use to write addresses, but what's with the <phone> tags?
I find <address> and some other tags totally useless.
One last thing. What do you see as a biggest disadvantage of creating
your own XML Schema for the "HTML"? I created a small test page months
ago and tested it in IE and FireFox. Basically, this is the story: I
create XML Schema, create XML document and XLST file that transforms my
XML to XHTML. It's working fine, but I'm concerned about downsides of
making those pages public. I think I can count off all mobile devices
then, can't I?