RE: XHTML 2.0 considered harmful)

Here is my take on this issue then I will leave this one alone.
 
My feeling is that style should be kept for certain elements for
individual styling of the elements.  For example, if I had say three
different element areas.  If I wanted one as underlined, one as
underlined and bolded and another as underlined and italics,  That is
three different styles classes.  If within those elements I wanted to
turn off the style, that is another style class (to turn off formatting
within the inline tag), if I then wanted to bold something within that,
then that is another class.
 
While ids could be used as well for specific instances, it is not good
to do that in my opinion because you would need to create a style for
each individual ID.  And you should not duplicate Ids because the ID
uniquely identifies the tag.  If you have duplicates, that will confuse
the DOM and also cause problems in scripting.
 
While I do believe that for multiple instances of a style that you
should use a class, the single instance of underlining one word or
bolding a small number of words should be able to be handled through
styling the single instance.  Creating a class in that case may be too
much overhead.  Besides, like mentioned before moving the contend with
the intended styling would be a benefit.
 
I know that "the content" should be free of styling, but many times the
styling helps define the context of the content.  And if that is the
case then the style should "follow" the content around so that the
original context is maintained no matter where the text is moved.
 
That is just one way I look at it.  While I can work around without it,
the style attribute is effective when used in the instances where single
use and context of the markup is important.
 
And while the bold and underline may be a little simplistic, you could
get very complex with the various attributes available and only need it
for that one instance.
 
Anyway, that is how I look at it.  It would be a shame to loose it, but
it is not impossible to work around.
 
Richard Norman
Web/Application Developer
 
P.S. - the IDs should be used to identify objects within the DOM and
anchoring within documents in my personal opinion.  That's just one
man's view.  And I do like the l instead of br, but I do wish it stayed
ln or line instead of just l.

-----Original Message-----
From: Mikko Rantalainen <mira@cc.jyu.fi> 
Sent: Wednesday, January 15, 2003 8:51 AM
To: Tantek Çelik <tantek@cs.stanford.edu>
Cc: <www-html@w3.org>
Subject: Style attribute and BR vs L (was: XHTML 2.0 considered
harmful)




Tantek Çelik wrote: 
> On 1/15/03 7:06 AM, "Mikko Rantalainen" <mira@cc.jyu.fi> wrote: 
>>Ian Hickson wrote: 
>>>On Wed, 15 Jan 2003, Daniel Glazman wrote: 
>>> 
>>I agree. It seems that those who prefer br over l are the same ones
that 
>>want to keep the style attribute. 
> 
> False.  I prefer <L> over <BR> as a wrote in this thread already, and
I want 
> to keep the style attribute. 

Well, I'm afraid you're an exception. I cannot imagine even one valid 
reason to use br instead of l. 

>>If you feel that you have to use br or style attribute try to think
for 
>>a second what's the reason you "need" those. Think about *why* you're

>>trying to achieve the line break or specific styling, not *what*
you're 
>>trying to achieve. 
> 
> If you cannot see the need for the style attribute, it may simply
indicate 
> that you have not experienced the real world situations where it is 
> necessary.  

Please, *show* me a real world example where style attribute cannot be

easily replaced with id + CSS and the situation isn't because of 
brain_dead administration. If administrator is too dumb to fix the
issue 
deeper in the system then the site should be using old transitonal 
document types anyway. 

Everyone defending style attribute just repeats how that's needed in 
real world problems but nobody is seems to be able to show even one 
reaso
nable example. 

> I think this is in general the problem with the discussion of the
'style' 
> attribute.  On one side there are semantic purists that don't
understand 
> what the problem is and therefore claim there is no problem, and on
the 
> other side there are _experienced_ folks that have seen numerous real
world 
> situations where the style attribute is not only useful, but
essential. 
> 
> These real world situations have been listed in threads in this list,
but 
> always ignored or belittled. 

Perhaps those issues weren't big enough to justify the style attribute.

With the help of a good enough example, I'm sure we can generate enough

noise to get the style attribute back *if* it's really needed. 

As I said, style attribute shouldn't be kept just to workaround messed

up markup. I'll change my mind about this issue immediatly somebody can

show an example where the markup is logical but use of style attribute

still makes sense. 

And just for the record, I've programmed multiple systems that use CSS

and class attributes for all the styling needed. 

>>And what comes to teaching a document markup language to new people,

>>XHTML2 looks like much simpler as a whole than XHTML1.x. 
> 
> Then don't call it XHTML2.  Call it something else, like "SHML"
(Simplified 
> Hypertext Markkup Language). 

What makes you think that XHTML2 is so far from XHTML1.1? The missing
br 
or h1_h6 elements? The missing style attribute? IMO, most of the
changes 
are pretty trivial__but still needed IMO__and simply upgrading *major*

version number should be enough. Just like any software/development 
library/anything you use might be incompatible with previous version 
once the major version number changes. If XHTML2 sounds too scary for 
many people, then concurrent development should be started for
XHTML1.2. 

__ 
Mikko 



--- 
Incoming mail is certified Virus Free. 
Checked by AVG anti-virus system ( HYPERLINK "http://www.grisoft.com"
\nhttp://www.grisoft.com). 
Version: 6.0.434 / Virus Database: 243 - Release Date: 12/25/2002 
  


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.434 / Virus Database: 243 - Release Date: 12/25/2002
 

**************************************************************************************************
The contents of this email and any attachments are confidential.
It is intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or  the 
sender immediately and do not disclose the contents to any one or make copies.

**************************************************************************************************

Received on Wednesday, 15 January 2003 12:49:44 UTC