[whatwg] Default (informal) Style Sheet

[Sander Tekelenburg]

At 03:38 +0200 UTC, on 2007-04-01, Asbjørn Ulsberg wrote:

[...]

> While I'm a strong believer of separation between
> structure (HTML), presentation (CSS) and functionality (JavaScript), I
> think it could be useful for the HTML specification to -- within limits --
> define how each and every element's default CSS properties and values
> should be like.
>
> This could improve interoperability in the presentation layer, since no
> author starts with a blank canvas when composing his style sheet.

FWIW, the WRI requires AWPSs[*] that generate CSS to include a 'CSS zapper':
<http://webrepair.org/02strategy/02certification/01requirements.php#req26>.

What would your proposal achieve that an author provided 'CSS zapper' does not?

I can think of a few downsides:
- The ideal presentation of something cannot be defined universally. What
works well in one browsing environment doesn't necessarily work well in
another.
- It takes ages to define and implement a spec. Leaving UAs no room to in the
mean time improve their built-in Style Sheets will slow down development.
- Built-in Style Sheets leave UAs room to distinguish themselves from their
competitors and can thus be an incentive to innovate, which can in turn make
all UAs grow towards more maturity.
- The user may well have changed the built-in Style Sheet to some other
default, so authors won't be able to rely on a certain default presentation
anyway.

Why should these downsides be acceptable?

Leaving aside whether the objective is desirable, I doubt this could even
ever result in the objective. Even if HTML would spec a default presentation
for everything, then still authors can not rely on every browser actually
implementing that. So they'd still need to use a 'CSS zapper'.

Frankly, I can't even imagine that we'd be able to agree on a default
presentation for everything. So I suspect that at best this could result in
an incomplete list of default styles, which would mean authors would have to
provide a 'CSS zapper'.

The fact that you already say "within limits" (what limits exactly?) and
"informal" (in the Subject) mean suggests you are aware of these issues.

At 12:28 +1000 UTC, on 2007-04-01, Lachlan Hunt wrote:

[...]

> Yes, that will be defined in due course.
>
> http://www.whatwg.org/specs/web-apps/current-work/#rendering

That saying "when scrolling a page to a fragment identifier, align the top of
the viewport with the target element's top border edge", seems to emphasize
my argument. This is a silly requirement. When the anchor is near the end of
the document, it would result in empty space below the document (what should
happen with bottom fixed positioned content?). I doubt users and Web
publishers would appreciate that and that UA authors would implement that.

What instead this should say is something like "When taken to a fragment
identifier, UAs must clearly indicate the referenced point in the content to
the user". Because that *clarity* is what counts, not *how* that clarity is
provided. For example, a UA could indicate the target by hiliting it for a
couple of seconds, as iCab does. To me, as a user, that's a way more useful
and elegant solution. Similarly, it would make sense for the spec to say that
"by default, occurences of title attributes must be clearly indicated to the
user", and "occurences of LINK elements must be clearly indicated to the
user". But not *how* they should be indicated.

Who are we (as spec definers) to decide that x is the only correct behaviour
or presentation? And why should we want to stifle innovation by requiring
some specific presentation?


[*] Automated Web Publishing Systems.


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