[whatwg] [html5] Rendering of interactive content

[Smylers]

Giovanni Campagna writes:

> 2009/2/8 Smylers <Smylers at stripey.com>
> 
> > Giovanni Campagna writes:
> >
> > > data:text/html,<style>label { position:fixed; top:-1em; border:1px
> > > solid black; } label input { -moz-appearance:none;
> > > -webkit-appearance:none; border:none; width:auto; }
> > > input[type=submit] { -moz-appearance:none;
> > > -webkit-appearance:none; background-color:transparent;
> > > border:none; }</style><form action="http://www.google.com/search"
> > > method="get"><label>Search: <input type="text" value=""
> > > name="q"></label><input type=submit value="Go">
> > >
> > > Imagine that was the UA default stylesheet instead of an author
> > > stylesheet and you may see what interoperability means with web
> > > application look and feel.
> >
> > Indeed it would be a problem if a major web browser shipped with such a
> > default style-sheet. But ... I'm really having trouble imagining any of
> > them doing so.  It isn't in mainstream browsers' interests to produce
> > products which purposefully confuse their users.
> >
> > Surely a browser which disguises buttons as plain text is going to lose
> > market share of its own accord, regardless of what HTML 5 says?
> 
> 
> > Or, to look at it from the opposite direction, supposing a browser
> > producer really wanted to make buttons look like plain text, would
> > whether HTML 5 condemns this practice really affect what they do?  Would
> > not being able to market their browser as HTML-5-compliant be enough
> > that they'd begrudgingly forget their desire?  Would users dissatisfied
> > with the behaviour only complain because it breaches HTML 5, rather than
> > because, say, it's really stupid?
> >
> > I can't see how a requirement such as you propose would make any
> > practical difference on avoiding the outcomes you wish to avoid.  But it
> > might unnecessarily curtail innovation in directions that we haven't yet
> > envisaged -- perhaps somebody developing a specialist user-agent for
> > mobile devices (or digital TV, or for print-based output, or
> > large-screen non-interactive displays, or ...) comes up with a different
> > way of displaying certainly elements which she considers is superior for
> > her particular target audience; why should the spec attempt to dissuade
> > her from doing so?
> >
> > Smylers
> >
> 
> I agree with you that we must not constrain the innovation, but in that
> case, what is the whole purpose of the Rendering section?
> I think that section is for
> - implementors of new UAs, that don't need to reverse engineer the
> competitor products in order to find the defaults

Yup -- it means that somebody creating a conventional graphical web
browser can straightforwardly produce the output of other such web
browsers, and that authors expect.

> - authors, that in this way know what to expect from the various UA

Yes.  But note that expectations are merely that; expectations are not
always met!  And there may well be instances in which a user-agent for a
particular market decides to different rendering would better suit that
market; users of such a device are likely to appreciate it -- and
whether the author expected it (or even became aware of it) doesn't
necessarily matter.

> Having somewhere written that hyperlinks should be blue, allows you to
> style the background-color to anything but blue.  If the UA suddenly
> displays hyperlinks in green and I decided that my background is
> green, the user will complain with me,

Indeed.  That's precisely why they should only be labelled as
expectations and not things an author can rely on.  The only sane
options for an author are to set no colours at all or to specify both
background and text colours.  It is not safe only to set one of them,
and it would be irresponsible for HTML 5 to give the impression that it
is.

(Remember that even if all browsers implement the provided defaults,
users can still set a preference of green links or whatever.)

> The solutions are two:
> 1) either provide a default style sheets only for author and say: "you
> want the usual rendering everywhere? import this". This means that the
> whole Rendering sections should be moved to an Appendix and a separate
> downloadable CSS file should be provided.

That's very close to what we have got.

Except that it isn't in an appendix; it's in a non-normative section.
But the important point is that it isn't normative.

And that a browser producer is permitted to choose to implement them by
default rather than expecting users to have to import them.

Consider if a future release of Firefox didn't contain the CSS for
expected web rendering, but users could import it should they want to.
It turns out that nearly all users desire this rendering; this new
Firefox release and they find it tedious to have to specify it
separately (if indeed they are technical enough to have discovered how
to do so; many simply consider that Firefox release to be broken).

So somebody takes the Firefox source code, adds in the default user
styles, and releases it as Snowchicken.  Most users prefer Snowchicken
over Firefox, so Snowchicken gains market share.

Are you suggesting that it would be better for Snowchicken to be deemed
_not_ to comply to HTML 5 because it includes this default styling that
you wanted to be only for users?

If so, please can you explain what the advantages are.

If not, and you believe Snowchicken should still comply, please can you
explain how your preferred situation differs from what's current in the
spec.

Smylers