RE: comments on 2002-12-12 XHTML 2.0 WD

After thinking about this, I believe the the style attribute is good for
single instance items like mentioned below.  Other wise the CSS classes
could become over used and too much overhead.  But hey I can work around
not having it, but with having it, there is no need to force markup to
create classes just to handle underlines and such...
 
Sincerely,
 
Richard K. Norman II
Web/Application Developer
Saint Agnes Medical Center
 
Email: Richard.Norman@samc.com

-----Original Message-----
From: John Lewis <lewi0371@mrs.umn.edu> 
Sent: Wednesday, December 18, 2002 3:31 PM
To: <www-html@w3.org>
Subject: Re: comments on 2002-12-12 XHTML 2.0 WD




Mikko wrote on Wednesday, December 18, 2002 at 8:54:03 AM: 

> Daniel Glazman wrote: 
>> I deeply regret that the style attribute was dropped. [...] 

> There's something wrong deeper in the structure if you need to 
> specify styles inside the content. Normal elements with classes 
> should be enough for everything. Could you provide an example where 
> you absolutely need specific style for something and yet that 
> something isn't generic enough for the required style to be added to 
> the global stylesheet as a new class. 

It's a waste to specify a style in a global style sheet if you use it 
on one page. In that case, it's usually best to use a class specified 
in the head element of the single page (or in an external style sheet 
for the single page). However, in the case where a style is used 
*once* on a *single* page, there may be no reason turn it into a class 
(equally, there may be reasons to). In those cases, where there is no 
way the meaning can be expressed in XHTML, the style attribute is a 
matter of author convenience (or "choice"). For example, the style 
attribute is handy in CSS tutorials and CSS test case bugs in 
browsers. If a style is better suited to a class, the author will put 
it in a class (for their own selfish reasons). If the style is not 
suited to a class, I see no reason to force authors to use classes. 

I don't think we need to prove that we *need* the style attribute; 
after all, with the style attribute, you don't *need* to define styles 
through classes (but it is a convenience). However, both are handy, 
and useful in different cicumstances (in my experience). 

I think, at most, XHTML 2.0 should strongly encourage authors to use 
classes and external style sheets where appropriate, and discourage 
authors from using the style attribute, instead of outright removing 
the style attribute. 

>>    (a) I think that all presentational elements but three should be 
>>        forbidden in XHTML. The only allowed elements should be,
because 
>>        of their super wide use and because NO, you don't always want
to 
>>        add semantics to a piece of text you want to see in
bold_italic, 
>>        B I and U. 

> I think U should go away simply because most UAs use underlining for 
> links. 

I think 'u' should go away because it's an element of dubious value. 
If you absolutely cannot define the underlining you want in a style 
sheet, your recourse should not be to be adding a purely 
presentational element to a mostly structural language. I think this 
is another example where the style attribute is (or could be) 
desirable. It's better to let authors write terrible documents by 
using/abusing style sheets than it is to create a terrible markup 
language to suit them. 

> Please no. There's no reason to include any styling into the 
> content. 

The question is, what reason is there for excluding styling from the 
content? In cases where you replace an inline style with a class, you 
don't remove the content's need of the style (if there is one), you 
instead moved where you defined the style. I don't see how getting rid 
of the style attribute forces or even encourages authors to write 
better markup, yet I do see it has disadvantages for document authors. 

> This is our first chance to get rid of styling mixed in the content. 
> I'm hoping to be able to use XHTML+CSS for printed page authoring 
> too and I really hope there the content author isn't able to mess up 
> with the style I've defined for the document. 

As the user, you should be able to override any author styles. 

> HTML isn't page layout tool. It's for marking up the structure of 
> HTML. If XHTML2 did include normative stylesheet how would that make 
> things any easier because visitor could still have user stylesheet 
> overriding that normative stylesheet. Author stylesheet must contain 
> all the stuff the author considers important. Remember that author 
> stylesheets are for hinting anyway so the content must be marked up 
> correctly. 

> I think the strength of XHTML when compared to other systems is that 
> layout doesn't NEED to be the same. In fact, it must not look the 
> same because different users have different needs. A simple example 
> is a person with vision problems so that she needs letters to be 
> like 10 centimeters high to be able to read those. In addition she 
> cannot see any colors so only light intensity can be used to render 
> information. If the page author could force the layout, font size, 
> color or something like that the user couldn't read the content. 
> IMO, XHTML should be accessible over everything else. 

Well said. I agree. However, even with a normative style sheet for 
XHTML 2.0, you can override anything with a user style sheet, which 
means the above is not a reason to not create a normative user style 
sheet. One good reason is that it restricts the freedom of browsers 
(but not people) to cleverly present markup in new, easy to understand 
ways. 

> I agree that we should have only one list type but I think instead 
> of boolen "ordered" attribute we should have "type" attribute (I'm 
> aware that some people think that type should be reserved to content 
> type) so that in the future list types could be extended. 

I agree that it's a good idea to have one list element with multiple 
types, however it is accomplished. 

>> 8. Anchors (sources of a link) are still mono_target. This is a pity.

>>    There should be an inline_level element containing a elements. Ex:

>> 
>>      <link> <!__ I am using that name on purpose __> 
>>        <a href=" HYPERLINK "http://www.w3.org/TR/xhtml"
\nhttp://www.w3.org/TR/xhtml">XHTML 2.0</a> 
>>        <a href="htttp://www.ercim.org/xhtml">XHTML 2.0 
>>           (Mirror at ERCIM)</a> 
>>      </link> 

> I don't follow. Why do you need such a thing? Should UA render only
the 
> first link by default and provide a method to access the alternative 
> references? If both of those should be rendered inline by default,
how's 
> that different from simply providing both links one after another 
> without enclosing those in a yet another element? 

I think the UA is supposed to try the first link__if it works, fine. 
If it doesn't, then try the second link, which is a mirror of the 
first. 

__ 
John 


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


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.431 / Virus Database: 242 - Release Date: 12/17/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.

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