W3C home > Mailing lists > Public > www-style@w3.org > May 2002

RE: canvas <html> <body>

From: Manos Batsis <m.batsis@bsnet.gr>
Date: Wed, 8 May 2002 10:37:02 +0300
Message-ID: <E657D8576967CF448D6AF22CB42DD2690FF274@ermhs.Athens.BrokerSystems.gr>
To: "George Lund" <george@lundbooks.co.uk>
Cc: <www-style@w3.org>

Sorry for the delayed response, I was on a holiday break.

> From: George Lund [mailto:george@lundbooks.co.uk] 

> >> Generic mark-up is *not*for use on the WWW; only predefined
> >> applications
> >> agreed between the parties in advance.
> >
> >I have to partially disagree; again, the applicability of 
> CSS to style
> >any XML vocabulary depends on the vocabulary structure when compared
> >with it's semantics.
> What does this mean?  If you have a particular XML 
> vocabulary, for which 
> you know the browser has a style sheet, then there is no 
> problem. Both 
> parties have prior knowledge of the XML vocabulary concerned 
> and we are 
> not talking about generic mark-up.

You just said "Generic mark-up is *not*for use on the WWW" didn't you?
To clarify on the semantics VS structure; display of an XML document
should be according to needs and that, depending on the targeted user
(author, simple viewer etc) is to expose a certain part of the
semantics. These may, or may not be according to structure, which makes
rendering a much more complicated issue. For the simplest example, you
may wish to expose attribute values of an XML document.

> >> We shouldn't confuse
> >> the way one
> >> browser (Mozilla) has chosen to implement XHTML with the
> >> principles of
> >> separated style and semantics.
> >
> >Mozilla is considered the best implementation thus far. Also, that's
> >what 'cascading' is all about ;-)
> Mozilla may be the best implementation so far but that does not mean 
> that it is the W3C recommendation - it is just one implementation. 

Fair enough.

> A 
> 100% compliant (X)HTML browser need understand no CSS *at 
> all*. 

That is correct.

> This is 
> the type of browser we can expect to see on some portable devices.

I personally expect support of stylesheets in mobile devices and
resources permitting, it would be a wise choice on the device vendor's
part. CSS Mobile profile[1] for example was designed specifically for
this. XHTML basic also supports linked stylesheets[2].

> > That's why all my stylesheets have
> >
> >html,body{width:100%;height:100%;}
> Why?  Are these style sheets for your XHTML files or for some 
> arbitrary 
> though well-formed XML that happen to be similar to XHTML?

The documents belong to the namespace in [3] and are valid against one
or more XHTML DTDs. Based on the conversation context your question is
somewhat misplaced.

> If they are 
> XHTML then the whole point of using XHTML is that there will be some 
> default (cascaded!) presentation.

There is, but it does not cover my needs of covering at least one screen
full as you say below. It may seem awkward, but how would you handle the
default presentation of the html element if you designed a browser? 
The point is whether you can think of a better way to handle the html
element besides using a default stylesheet rule. I don't, because I
another way would produce conflicts with the presentational foundations
of XHTML including cascade.

>  So you don't *need* to include any 
> CSS, much less something as unlikely to have an effect as that 
> particular rule! 

Because I want to cover at least 100% of the screen.

> (Aside: why restrict your pages to a single 
> screen-full as your rule seems to do?)

I'm not, although I could add an overflow rule at that.

> > This will make XHTML
> >easier to use as vanilla XML to store data, which is what 
> separation of
> >content and presentation is about.
> That sentence doesn't make sense.  

Perhaps it's just you that can't make sense out of it.

> Do you mean 'XHTML will be 
> as easy to 
> use
> a vanilla XML'? 


>If so, what is vanilla XML?  It doesn't *mean* 
> anything.

...to you. I meant any custom XML vocabulary, sorry, I thought it was a
rather common, unofficial term.

> It has *no* semantics unless the browser is already 
> aware of 
> them.

XML documents may have many semantics, not all addressable by a single

>  If you rely on author CSS in order to make your 'vanilla XML' 
> renderable then you have made a serious accessibility mistake and 
> *completely* misunderstood why it was necessary to move the 
> presentational aspects out of HTML in the first place. 

I'm sorry I don't get that. Perhaps then you can further explain your
claim of my accessibility mistake as well as what 'structured documents'
means in the first sentence of the Abstract at [4].

> 'Vanilla XML' is 
> a part of one recommended solution to data management *on the server* 
> and within organisations.

You are right in that you have not interpreted the term correctly.
'Vanilla XML' is a rather context sensitive but convenient term; it
usually means XML when processed by applications outside it's main
target, or XML not belonging to a major vocabulary, meaning a custom XML

[1] http://www.w3.org/TR/css-mobile/
[2] http://www.w3.org/TR/xhtml-basic/#s1.3
[3] http://www.w3.org/1999/xhtml
[4] http://www.w3.org/TR/REC-CSS2/
Received on Wednesday, 8 May 2002 03:37:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:01 UTC