Re: [whatwg] Default (informal) Style Sheet

<p06240601c23d8733a613@[192.168.0.101]>

Current votes: None.


At 5:38 PM +0200 UTC, on 4/7/07, Alfonso Mart=EDnez de Lizarrondo wrote:

> 2007/4/7, Sander Tekelenburg <<mailto:st@isoc.nl>st@isoc.nl>:
>
>> It seems extremely unlikely to me that every UA will in fact implement=
 the
>> exact same default Style Sheet, even it it were mandated by the spec.
>> Therefore, in reality authors will not be able to rely on this and thu=
s
>> speccing it, giving authors the impression they can rely on it, is lik=
ely to
>> be result in more problems for users, not less.
>
> So it comes down to this:
> You don't trust that the UA will implement the default Stylesheet, and =
so
>you say that every UA can do what they want because you propose that eve=
ry
>web author include that CSS Zapper.

That's not at all what I said. I listed 4 specific objections initially. =
So
far people are responding to details only.

All I said in what you're responding to is that [1] it seems unlikely to =
me
that UAs will actually all use the same default Style Sheet and [2] users
will still have User Style Sheets, and that therefore the argument of
"ensuring Web pages will look the same across UAs" doesn't fly.

That doesn't mean I don't still question whether it is *desirable* at all=
 to
try to make Web poages look the same across UAs. It doesn't mean I don't
still question that such a goal would even be achievable, because the sam=
e
presentation will not work well in different browsing environments (inden=
ting
lists 40px is a waste of screen real estate on mobiles). And it doesn't m=
ean
that I don't still think that speccing a default presentation will make i=
t
harder for UAs to improve their default Style Sheet.

I *do* recognise the problem that currently most authors do not consider =
the
fact that UAs have default Style Sheets. So they end up serving CSS that
relies on that built-in Style Sheet, resulting in problems when that buil=
t-in
Style Sheet is different from what the author anticipated.

Authors can handle this reality in two ways
[1] when you want padding:0, explicitly state so instead of relying on th=
e
fact that some UA already uses that as the default
[2] have your CSS start out with a 'CSS zapper'.

That second approach is easier for most authors, and is implementable for
authoring tools, which is why it seems the best approach to advocate.

> Some web authors will implement a CSS zapper to achieve the goal of hav=
ing
>the same rendering in all the browsers

That would be a misguided argument. The goal of using a 'CSS zapper' is t=
o
avoid relying on UAs default Style Sheets. I'm not claiming it would ensu=
re
sites look the same across browsers. I in fact oppose that goal.

>, but too many web authors will focus
>just on the browsers that have the most usage

Maybe. I think advocating CSS authors include a 'CSS zapper' in their CSS=
 is
a simple enough 'trick' that there is a reasonable chance authors will pi=
ck
up on it.

But assuming authors won't, I still don't see how the spec aiming to "ens=
ure
Web pages will look the same in every browsing situation" could possibly =
have
better results, while I *do* see serious potential downsides to that appr=
oach.

> and new browsers will have to
>reverse engineer and copy those de facto standards that aren't documente=
d
>anywhere or too many websites will look wrong.

Yes, that's the one argument that seems to make sense to me thus far. But=
 it
should still be weighed against the objections.


--=20
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>