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

Daniel Glazman wrote:
> Important disclaimers:
> 2. I deeply regret that the style attribute was dropped. I would like
>    the XHTML WG to explain how can I copy an element (+contents +
> style)
>    from one XHTML2 instance to another one if I can't modify
>    an external stylesheet nor create a new one (that's often the case
> in
>    cooperative editing systems).
>    The best system for copy/paste seems to me the existence of the
>    style attribute, populated with all CSS properties having a computed
>    value different from their initial value.

I don't agree. I hope XHTML2 doesn't have style attribute nor b, i or u 
elements.

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.

IMO, if you need to copy-paste stuff around that is related to styling 
you're doing something wrong.

>    (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. As for B and I elements, I would get rid of those those and 
replace both with EM. Most current UAs already render I and EM 
identically and I think nested EMs should be rendered as bolder.

If B and I elements are kept, their recommended usage should be the same 
as with SPAN, but B and I had default renderings "bolder" and "italics". 
For some things, there isn't adequate element available in the XHTML and 
we should reserve a couple of generic inline and block elements with 
*different* (not necessarily fully defined by the spec) rendering for 
document to make sense without extra stylesheet. We currently have B, I, 
SPAN, DIV and LINE for such a things.

>    (b) I think that presentational attributes should be allowed in

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

>    (b++) The spec should recommend that other visual media infer
>        default CSS styles from that default screen stylesheet.

I think recommendation is too much. It might be hinted that if author 
doesn't provide any style for the media UA can support, the UA should 
provide a preference for the user to use screen media instead. No way 
should such a action be recommended default because that only invites 
sloppy authoring.

>    (c) that way, we can add to XHTML all the stuff Web authors have
>        consistently asked for since 1998: bgcolor and bgimage attribute
>        on all elements, height attribute on table, ...

Oh, please no! This is our first change 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. Everything that 
makes using of incorrect elements for the content easier is bad (e.g. 
modifying the rendering of incorrect rendering to resemble the rendering 
of correct element).

> 4. I think that the lack of a default NORMATIVE stylesheet for XHTML 2
>    is an error that all HTML dialects have consistently made and that
>    XHTML 2 should fix. Without such a normative stylesheet, we will
> have
>    rendering differences between browsers and that's not a price Web
>    authors should have to pay.

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.

>    to make sure XHTML is *really* a lingua franca. Without a normative
>    stylesheet for screen, it can't be a lingua franca.
>    In particular, the new elements XHTML 2.0 introduces like NL have no
>    historical record on the Web. Without a normative style definition,
>    I bet we'll have different renderings for them in different implems.

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.

Just for the record, I allow all author stylesheet hints but those that 
try to force more ads on me. Oh, and I do have minimum font size set to 
9px because way too many web pages do have incorrect font size hinting 
in the author stylesheets.


> 7. The simplification of headings is hardly understandable when
> different
>    list elements remain in XHTML 2. Why remove h1-h6 in favor of
> heading
>    and keep ol-ul ? Let's be consistent here and remove ol-ul in favor
>    of a list element with one 'ordered' attribute with value
> true|false.

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.

>    a link or source of a link. The name attribute of a SHOULD NOT be
>    meaningful for named anchors and only id should allow targeting of
>    fragment-identifiers.

I agree. In additiong, forms should be fixed so that name attribute 
could be removed.


> 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?

> 9. Link types should allow "icon" for rel/rev. That's proposed by

I agree. When I've multiple tabs open it is huge usability plus to have 
different icons for different sites. If UA supports any image formats 
for icons the PNG must be supported. Icon links should be allowed to be 
listed multiple times with different values. This allows author to 
provide sound file for aural agents. I'm not sure how aural browsers 
should render the icon but I think we need to provide similar support 
for those too.

> 10. section 12.1: "We should specify a minimal set of useful meta
>    properties". I disagree with that. The HTML WG should specify a
>    MAXIMAL set of useful meta properties. Web authors have consistently

I think meta should be reserved for future extensions if possible and if 
we want to include required meta information then we should use one 
element for every piece of required information. e.g. 
<head><title/><author/><date/><etc/></head>

-- 
Mikko

Received on Wednesday, 18 December 2002 09:54:02 UTC