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="http://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

Received on Wednesday, 18 December 2002 18:39:39 UTC